3 ms·

This article goes into more detail of RPM: https://xyrillian.de/thoughts/posts/argh-pm.html https://xyrillian.de/thoughts/posts/argh-pm.html

by Leace 7y ago

majewsky 7y ago
Came here to say the same thing. ;)
dang 7y ago
Should we change the URL to that above?
- DyslexicAtheist 7y ago
  cruel :)
- iamcreasy 7y ago
  Don't. It's a proof that the comment section is awesome!
eeZah7Ux 7y ago
This should be upvoted.
gcbw2 7y ago
Came for the click bait title of the original article, stayed for the awesome comments :)
DyslexicAtheist 7y ago
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. [1] https://twitter.com/foone https://twitter.com/foone
- wahern 7y ago
  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.
  - Conan_Kudo 7y ago
    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?

This article goes into more detail of RPM: https://xyrillian.de/thoughts/posts/argh-pm.html https://xyrillian.de/thoughts/posts/argh-pm.html

by Leace 7y ago

This article goes into more detail of RPM: https://xyrillian.de/thoughts/posts/argh-pm.html https://xyrillian.de/thoughts/posts/argh-pm.html

majewsky 7y ago

Came here to say the same thing. ;)

dang 7y ago

Should we change the URL to that above?

DyslexicAtheist 7y ago
cruel :)
iamcreasy 7y ago
Don't. It's a proof that the comment section is awesome!

eeZah7Ux 7y ago

This should be upvoted.

gcbw2 7y ago

Came for the click bait title of the original article, stayed for the awesome comments :)

DyslexicAtheist 7y ago

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. [1] https://twitter.com/foone https://twitter.com/foone

wahern 7y ago
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.
- Conan_Kudo 7y ago
  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?