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.

@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

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!