4 ms·

After spending years messing with RPM packages in the sysadmin world, I now breathe a sigh of relief with Arch/pacman. Building/maintaining/installing RPMs is p

After spending years messing with RPM packages in the sysadmin world, I now breathe a sigh of relief with Arch/pacman. Building/maintaining/installing RPMs is painful compared to Arch or Debian's dpkg.

debiandev 7y ago
Having worked a lot with RPM, other package managers, containers and proprietary build systems... I would choose debs every time.
- stirfrykitty 7y ago
  Having said what I did above, though, can anything compare to SUSE's command to update? "zypper -up" Best command ever...
  - DyslexicAtheist 7y ago
    the initial (buggy) versions of zypper replacing Yast was what drove me away from SuSE for good. Never had much love for SuSe but what really killed it for me is when I worked as a consultant (a company that was a SuSE premium reseller) and I was the poor sod trying to integrate their solutions in large companies that didn't have IT/Tech as their core business (hospitals, government etc). I still have flashbacks to their SLOX (suse linux open exchange) and SLES which both were the buggiest distros I ever had shoved down my throat. I felt sorry for my customers. Once the whole IT of a hospital stopped working because of some bugs in their LDAP migration. I need therapy just by reflecting about this and their general way of how they handled root causes back then. From your comment it seems SuSE must have improved since 2005. I didn't follow them for long time now. It's Arch or Debian for me these days.
- noselasd 7y ago
  I have the exact oposite experience. Building/packaging/maintainig my own software with RPMs is pretty straight foreward, whilst packaging the same software as .deb is a rollercoaster which often goes off track and down a deep hole.
  - wahern 7y ago
    RPM makes the simple easy and the difficult impossible. RPM's grace and sin is its simplistic, rigid, singular spec file. The startup costs to Debian packaging are greater. In the most basic case not that much greater--a single control file with intuitive fields, and a rules file (i.e. Makefile) with intuitive targets. However, to do things according to best practice (i.e. official Debian policy) often requires using additional tools and configuration files. So, yeah, it can become byzantine. But if you realize that it all comes back to generating that control file and rolling up a target directory, same as RPM, it can be easier to make sense of everything. The important distinction is that all the complexity, required and optional, in Debian packaging can be hidden within the confines of the packaging framework. That is, whatever your build rules and workarounds, anyone trying to build your package can just invoke a standard dpkg build without having to understand any of it. Working around deficiencies in RPM often requires adding and exposing additional layers of complexity, like generating spec files in ad hoc pipelines before a user can invoke rpmbuild. For example, do you autogenerate your RPM package version from the source? How do you embed it within the spec file? And are you able to also generate a source tarball that can generate the same build? It's one thing to cobble together an RPM that explodes to some binaries; it's another to do so in an automated fashion that's also transparent--i.e. generates SRPMS that can be built within clean environments. I know, I know, CI/CD systems can obviate the need to build binary RPMs from SRPMs, but that's exactly my point. RPM alone is seriously deficient. There are lots of little problems like this that pop up when your needs become more complex; you end up building taller towers of complexity than what would be needed using Debian.
    - Conan_Kudo 7y ago
      You can build with rpmbuild without making SRPMS (pass -bb instead of -ba), but in my experience, most CI/CD systems do not provide clean, arbitrarily reproducible environments. That said, rpmbuild has grown features over the years to make it more compatible with that model. My experience with RPMs, Debian packages, and various other formats has led me to prefer some of the rigidity and explicitness of rpmspec over the sprawl of automagic that is a debian/ tree, and other similar things. But if you want to do weird things to build packages, nothing stops you from doing that and using a trivial spec file as the intermediate to pass instructions to rpmbuild to wrap it up. The format is not perfect, but I haven't seen anyone make any proposals recently about how to improve it on the rpm-ecosystem mailing list, the rpm-maint mailing list, the rpm project on GitHub, or at any of the developer conferences where rpm developers show up. You seem to have a ton of knowledge and opinions, why not engage with the project?
jle17 7y ago
I'm curious at how you find rpms more painful to build than debs ? I don't have much experience with them but I was under the impression than just writing a specfile and calling rpmbuild was a step up compared to debian, which seems a mess to me with the makefiles and other stuff all over the place and all those dpkg commands which are wrappers for each other.
- stirfrykitty 7y ago
  - Packages with mutually exclusive dependencies are troublesome in the RPM world - yum/dnf take extraordinary amounts of time compared to apt - debs are all in one source. Upstream sources are clean, predictable, and easy to troubleshoot.
JudgeWapner 7y ago
I still have flashbacks from circa 2000-2002 being in "rpm hell" and trying to install a single package on my system, only to find out it needs libutemptr-3.0.1.rpm, where as my yahoo searches only found a download for libutemptr-3.0.2a.rpm. I try downloading that anyway, wait 20m on my dailup connection, only to find that libutemptr needs libgdkpixbuf-7-9.01.rpm. 50% of the time, one of these dependencies would clash with whatever was already on my system and refuse to install. 49% of the time, it wouldn't be the right version so it wouldn't work anyway. and 1% of the time I could eventually make it work if I just extracted the content and changed my LD_LIBRARY_PATH to satisfy the dependencies manually. eliding the very purpose of rpm. rpm hell was the Dark Ages of FOSS, and I'm so glad that the community has resolved that problem. However, the bitter taste still lingers and for this reason I will never take rpm files seriously again.
- quicksilver03 7y ago
  Why do you blame rpm as a packaging format, instead of the maintainers of those rpm packages?
  - JudgeWapner 7y ago
    because a good format/protocol should be easy to use correctly, and difficult to use incorrectly.
pkulak 7y ago
I thought dnf was the new hotness in the package management world. Is apt still superior?
- wwright 7y ago
  dnf is a generational improvement over yum. It still uses RPMs behind the scenes.
- butteroverflow 7y ago
  apt was never superior. The biggest thing in dnf for me is transaction support. Basically, every time you do a package operation, dnf records the changes to its logs, and you can then revert it, downgrading the upgraded packages, installed the removed, and so on. You can also revert multiple transactions at once, e.g. restore the package versions to what they were three months ago. There's nothing remotely like this in apt -- if you install a lot of packages on your system, and then want to remove them, the common solution is something like "parse the (text) apt logs, learn manually what's changed, and revert it yourself". Some other niceties: * package groups: `dnf install @'c development'` instead of `apt install binutils gcc make bison yacc whatever-else`. Somewhat mitigated by metapackages, but they rarely cover the whole groups of functionality, i.e. they are often more low-level. * package streams: `dnf install node-8`, or `node-9`, or one of the other supported versions; * dnf downloads many packages in parallel, and the level of parallelism is configurable. This greatly helps with upgrades from slow mirrors. I believe it can also utilize multiple mirrors at once, though I haven't tried it. * dnf supports plugins and you can install them with a simple command. For example, there's a plugin to automatically create btrfs snapshots on every package upgrade. * COPR saved my skin a couple of times, though it's basically the same thing as Ubuntu's PPAs. This is more of a problem for Debian.
  - pkulak 7y ago
    Interesting, thanks. How do you automatically revert a setup script though? Can you just not have setup scripts with dnf?

debiandev 7y ago

Having worked a lot with RPM, other package managers, containers and proprietary build systems... I would choose debs every time.

stirfrykitty 7y ago
Having said what I did above, though, can anything compare to SUSE's command to update? "zypper -up" Best command ever...
- DyslexicAtheist 7y ago
  the initial (buggy) versions of zypper replacing Yast was what drove me away from SuSE for good. Never had much love for SuSe but what really killed it for me is when I worked as a consultant (a company that was a SuSE premium reseller) and I was the poor sod trying to integrate their solutions in large companies that didn't have IT/Tech as their core business (hospitals, government etc). I still have flashbacks to their SLOX (suse linux open exchange) and SLES which both were the buggiest distros I ever had shoved down my throat. I felt sorry for my customers. Once the whole IT of a hospital stopped working because of some bugs in their LDAP migration. I need therapy just by reflecting about this and their general way of how they handled root causes back then. From your comment it seems SuSE must have improved since 2005. I didn't follow them for long time now. It's Arch or Debian for me these days.
noselasd 7y ago
I have the exact oposite experience. Building/packaging/maintainig my own software with RPMs is pretty straight foreward, whilst packaging the same software as .deb is a rollercoaster which often goes off track and down a deep hole.
- wahern 7y ago
  RPM makes the simple easy and the difficult impossible. RPM's grace and sin is its simplistic, rigid, singular spec file. The startup costs to Debian packaging are greater. In the most basic case not that much greater--a single control file with intuitive fields, and a rules file (i.e. Makefile) with intuitive targets. However, to do things according to best practice (i.e. official Debian policy) often requires using additional tools and configuration files. So, yeah, it can become byzantine. But if you realize that it all comes back to generating that control file and rolling up a target directory, same as RPM, it can be easier to make sense of everything. The important distinction is that all the complexity, required and optional, in Debian packaging can be hidden within the confines of the packaging framework. That is, whatever your build rules and workarounds, anyone trying to build your package can just invoke a standard dpkg build without having to understand any of it. Working around deficiencies in RPM often requires adding and exposing additional layers of complexity, like generating spec files in ad hoc pipelines before a user can invoke rpmbuild. For example, do you autogenerate your RPM package version from the source? How do you embed it within the spec file? And are you able to also generate a source tarball that can generate the same build? It's one thing to cobble together an RPM that explodes to some binaries; it's another to do so in an automated fashion that's also transparent--i.e. generates SRPMS that can be built within clean environments. I know, I know, CI/CD systems can obviate the need to build binary RPMs from SRPMs, but that's exactly my point. RPM alone is seriously deficient. There are lots of little problems like this that pop up when your needs become more complex; you end up building taller towers of complexity than what would be needed using Debian.
  - Conan_Kudo 7y ago
    You can build with rpmbuild without making SRPMS (pass -bb instead of -ba), but in my experience, most CI/CD systems do not provide clean, arbitrarily reproducible environments. That said, rpmbuild has grown features over the years to make it more compatible with that model. My experience with RPMs, Debian packages, and various other formats has led me to prefer some of the rigidity and explicitness of rpmspec over the sprawl of automagic that is a debian/ tree, and other similar things. But if you want to do weird things to build packages, nothing stops you from doing that and using a trivial spec file as the intermediate to pass instructions to rpmbuild to wrap it up. The format is not perfect, but I haven't seen anyone make any proposals recently about how to improve it on the rpm-ecosystem mailing list, the rpm-maint mailing list, the rpm project on GitHub, or at any of the developer conferences where rpm developers show up. You seem to have a ton of knowledge and opinions, why not engage with the project?

jle17 7y ago

I'm curious at how you find rpms more painful to build than debs ? I don't have much experience with them but I was under the impression than just writing a specfile and calling rpmbuild was a step up compared to debian, which seems a mess to me with the makefiles and other stuff all over the place and all those dpkg commands which are wrappers for each other.

stirfrykitty 7y ago
- Packages with mutually exclusive dependencies are troublesome in the RPM world - yum/dnf take extraordinary amounts of time compared to apt - debs are all in one source. Upstream sources are clean, predictable, and easy to troubleshoot.

JudgeWapner 7y ago

I still have flashbacks from circa 2000-2002 being in "rpm hell" and trying to install a single package on my system, only to find out it needs libutemptr-3.0.1.rpm, where as my yahoo searches only found a download for libutemptr-3.0.2a.rpm. I try downloading that anyway, wait 20m on my dailup connection, only to find that libutemptr needs libgdkpixbuf-7-9.01.rpm. 50% of the time, one of these dependencies would clash with whatever was already on my system and refuse to install. 49% of the time, it wouldn't be the right version so it wouldn't work anyway. and 1% of the time I could eventually make it work if I just extracted the content and changed my LD_LIBRARY_PATH to satisfy the dependencies manually. eliding the very purpose of rpm. rpm hell was the Dark Ages of FOSS, and I'm so glad that the community has resolved that problem. However, the bitter taste still lingers and for this reason I will never take rpm files seriously again.

quicksilver03 7y ago
Why do you blame rpm as a packaging format, instead of the maintainers of those rpm packages?
- JudgeWapner 7y ago
  because a good format/protocol should be easy to use correctly, and difficult to use incorrectly.

pkulak 7y ago

I thought dnf was the new hotness in the package management world. Is apt still superior?

wwright 7y ago
dnf is a generational improvement over yum. It still uses RPMs behind the scenes.
butteroverflow 7y ago
apt was never superior. The biggest thing in dnf for me is transaction support. Basically, every time you do a package operation, dnf records the changes to its logs, and you can then revert it, downgrading the upgraded packages, installed the removed, and so on. You can also revert multiple transactions at once, e.g. restore the package versions to what they were three months ago. There's nothing remotely like this in apt -- if you install a lot of packages on your system, and then want to remove them, the common solution is something like "parse the (text) apt logs, learn manually what's changed, and revert it yourself". Some other niceties: * package groups: `dnf install @'c development'` instead of `apt install binutils gcc make bison yacc whatever-else`. Somewhat mitigated by metapackages, but they rarely cover the whole groups of functionality, i.e. they are often more low-level. * package streams: `dnf install node-8`, or `node-9`, or one of the other supported versions; * dnf downloads many packages in parallel, and the level of parallelism is configurable. This greatly helps with upgrades from slow mirrors. I believe it can also utilize multiple mirrors at once, though I haven't tried it. * dnf supports plugins and you can install them with a simple command. For example, there's a plugin to automatically create btrfs snapshots on every package upgrade. * COPR saved my skin a couple of times, though it's basically the same thing as Ubuntu's PPAs. This is more of a problem for Debian.
- pkulak 7y ago
  Interesting, thanks. How do you automatically revert a setup script though? Can you just not have setup scripts with dnf?