Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RPM Packages Explained

fedoramagazine.org

Post reply on HN
Print view View original

21–30 of 57 posts

Re: RPM Packages Explained

#21

Post by eeZah7Ux »

_pmf_ wrote: post #2

What's baffling to me is that there's support for signing,, but no support for an encryption layer. When delivering software updates for embedded devices, I need to do both, so I have to roll my own container format. This seems to also be the case with package formats like ipkg/opkg, which are targeted for the embedded use case.

The combination of IP addresses and package sizes is way too revealing. That's why APT supports Tor as a transport protocol.

Re: RPM Packages Explained

#25

Post by debiandev »

stirfrykitty wrote: post #22

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.

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

Re: RPM Packages Explained

#26

Post by jle17 »

stirfrykitty wrote: post #22

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.

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.

Re: RPM Packages Explained

#27

Post by stirfrykitty »

debiandev wrote: post #25
stirfrykitty wrote: post #22

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.

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

Having said what I did above, though, can anything compare to SUSE's command to update? "zypper -up"

Best command ever...

Re: RPM Packages Explained

#28

Post by stirfrykitty »

jle17 wrote: post #26
stirfrykitty wrote: post #22

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.

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.

- 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.

Re: RPM Packages Explained

#29

Post by JudgeWapner »

stirfrykitty wrote: post #22

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.

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.

Post reply on HN