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?
@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
@jon huh, I thought Arch used RPM?
@federicomena I don't think so - they use a manager called "pacman" and appear to use .tar.xz for the packages themselves
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!