Current status: backporting patches from rpm circa 2011 into rpm circa 2007, so I can build a specfile from 2017 on a (still supported) distro from around 9 years ago.

(Firefox 60 ESR wants Rust, which is not in Suse Linux Enterprise 11... rust.spec needs a non-ancient rpmbuild.)

Forgive me for not believing in RPM/DEB/similar packaging technology anymore.

Patch97: rpm-dont-delete-docdir.patch

This, kids, is what happens when you promise support for 10 years.

@federicomena Some of the Flatpak bashing seems to forget that both Flatpak and Snap are being made by groups of people who've had to put up with building distributions using RPM & DEB for decades.

@federicomena do you know *why* rpm and deb are... like that? comparing Arch Linux packages, what big advantage do rpm and deb get by being such huge pains to do properly?

@migratory @federicomena try backporting Fedora 60 ESR to an Arch from 2007 and then tell me RPM and DEBs are a pain ;)

@jon I've just had to pull in some patches from Firefox 62's deps to fix bugs in big-endian, put them in our 60ESR package... and re-vendoring Rust deps is a bit painful. The checksum checks really don't like it if one just patches the sources per RPM's standard practice; I had to really patch the results of re-vendoring through Cargo, so the checksums are recomputed.

The RPM part is clunky; the rust/cargo/re-vendoring part is kind of ok? I like it that the vendored tree remains consistent.

@federicomena to be clear; I agree that RPM/DEB approach has some serious drawbacks. I'm excited about things like Flatpak. But I don't believe Arch will fair better than RPM/DEB for this kind of work

@federicomena I don't think so - they use a manager called "pacman" and appear to use .tar.xz for the packages themselves

@migratory I think RPM has evolved gradually from what once was a very simple thing: just a way to encapsulate pristine sources, some patches to make the build compatible with the distro's practices, and some shell scripts to build the thing.

The whole thing got more complex as distros had to deal with thousands of packages instead of the few hundred we had in 199x.

The world wants more things now: checksummable sources, reproducible builds, more platforms. RPM hasn't evolved quite like that.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!