it's pretty crazy considering that RPM has been around since as long as I first installed Linux from floppy back in 1997.
no wonder rpm no longer get's much love. RPM is too old, but sadly not old enough. My hope is in 20 years time @Foone[1] will warm our hearts with a thread on how he used RPM's to install the gnu toolchain on a fedora based IoT toaster from 2000-late.
The current binary Debian package format dates to 1995. RPM doesn't get any love because RedHat never seriously committed to improving it. Maybe that's because it was a poorer design than Debian's. The Debian build system is more layered, which arguably makes it easier to extend and evolve. At some point RPM got embedded Lua, but it seems half-baked and because the build phases are too closely coupled I'm not surprised methods and protocols for extending things using Lua never emerged in practice--there aren't enough degrees of freedom in RPM's build model to make extensions seem more than just a hack.[1] In any event the situation could be better, there's just not enough will to do it.
[1] For example, IIRC Lua extensions in RPM were merely a convoluted way to extend RPMs macro system. You're still limited to simply defining macro variables in RPMs rigid templating and translation stages. Most of the complexity of RPM is in the places you least need it, and all the pain points are in places RPM doesn't permit you much, if any, freedom to tweak or automate.
In the times I've engaged with the rpm.org project, I've heard of ideas being floated about making the spec format better and even making a better package archive format.
But there's nothing concrete proposed by anyone for the rpm developers (or indeed anyone else) to consider for implementation.
We're probably at the point now where it's a good idea to start looking at it, but what should be done?
