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

31–40 of 57 posts

Re: RPM Packages Explained

#31

Post by _pmf_ »

0x006A wrote: post #3
_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.

whats the use-case for an encryption layer?

This is for embedded Linux devices with a set of proprietary applications (small volume commercial/industrial control, no consumer device). Mostly non networked, so we have to distribute application updates via USB (in the networked case, we a use VPNs separated by customer groups to deliver updates, so this layer provides the encryption without requiring the update archive to be encrypted).

Re: RPM Packages Explained

#32

Post by forgottenpass »

ses1984 wrote: post #12
ggg2 wrote: post #5

Earlier quoted context omitted.

hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that extra feature, manually download sensitive packages via ssl or something. everyone else (with nothing to hide, heh) keeps benefiting from a global cache of unencrypted transport of (mostly) open source data.

You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...

If by "origin" you mean "box Netflix has root on"... yes, I do think that?

Re: RPM Packages Explained

#33

Post by rhinoceraptor »

ses1984 wrote: post #12
ggg2 wrote: post #5

Earlier quoted context omitted.

hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that extra feature, manually download sensitive packages via ssl or something. everyone else (with nothing to hide, heh) keeps benefiting from a global cache of unencrypted transport of (mostly) open source data.

You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...

Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.

Re: RPM Packages Explained

#34

Post by quicksilver03 »

JudgeWapner wrote: post #29
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 clas…

Why do you blame rpm as a packaging format, instead of the maintainers of those rpm packages?

Re: RPM Packages Explained

#36

Post by pkulak »

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 thought dnf was the new hotness in the package management world. Is apt still superior?

Re: RPM Packages Explained

#37

Post by DyslexicAtheist »

Leace wrote: post #9

This article goes into more detail of RPM: https://xyrillian.de/thoughts/posts/argh-pm.html

it's pretty crazy considering that RPM has been around since as long as I first installed Linux from floppy back in 1997.

no wonder rpm no longer get's much love. RPM is too old, but sadly not old enough. My hope is in 20 years time @Foone[1] will warm our hearts with a thread on how he used RPM's to install the gnu toolchain on a fedora based IoT toaster from 2000-late.

[1] https://twitter.com/foone

Re: RPM Packages Explained

#38

Post by JudgeWapner »

quicksilver03 wrote: post #34
JudgeWapner wrote: post #29

Earlier quoted context omitted.

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 clas…

Why do you blame rpm as a packaging format, instead of the maintainers of those rpm packages?

because a good format/protocol should be easy to use correctly, and difficult to use incorrectly.

Re: RPM Packages Explained

#39

Post by noselasd »

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.

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.

Re: RPM Packages Explained

#40

Post by DyslexicAtheist »

stirfrykitty wrote: post #27
debiandev wrote: post #25

Earlier quoted context omitted.

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

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.

Post reply on HN