5 ms·

Now if they can just get rid of RPM I might come back!

by mergy 13y ago

Nux 13y ago
Do come back, it's better than the competition nowadays. :)
- BCM43 13y ago
  How so?
  - undoware 13y ago
    I'm not sure what the OP 'mergy' intended, but I'd guess that the intended reason had to do with better ecosystem curation. Under the hood, my understanding is that .rpm is marginally inferior to .dpkg, but not remarkably so. E.g. using cpio instead of gz as the format basis. So by elimination, the only reason to prefer .rpm would be the rpms, if you follow. As a longtime Fedora user and a recent emigre (post-Snowden) to OpenSuSE, I agree that there is much to love about the selection of RPMs available, especially under Fedora. Although I'm sticking with suse for the lightning-fast zypper (still noticably faster than yum or even its slated nextgen replacement dnf!) and well-thought-out snapper utilities. But that is OT.
    - matt__rose 13y ago
      Mostly it's a matter of picking your poison. dpkg allows some things that RPM doesn't, and vice-versa. dpkg does have some nice features (well, features I can't remember, except for I went "Ooo, I want rpm to have that" when I saw it) One thing that dpkg has that really annoys the hell out of me is allowing for user input during the transaction. It makes unattended upgrades impossible
      - YokoZar 13y ago
        In general Debian/Ubuntu packages do not prompt the user with debconf questions these days, although there are occasional leftovers in old packages if you upgrade via a terminal with apt-get update. You can define an environment variable, DEBIAN_FRONTEND=noninteractive, to force even the worst-behaved packages to never ask a question.
        tene 13y ago
        You can set those configurations, certainly, but it's up to the package maintainer to actually respect them. At my previous company, I occasionally ran into packages that insisted on trying to read from the terminal, even when installed noninteractively, with all configuration flags set to noninteractive. I can understand the potential appeal for a lone individual working with a small number of hand-maintained systems, but when working with a large cluster, interaction during package operations is just a horrible misfeature.
- mergy 13y ago
  It's been years, but RPM was always frustrating compared to the ease of apt.
ciupicri 13y ago
What's wrong with RPM?
- jebblue 13y ago
  For me in past years on Red Hat, Fedora and SuSE the RPM repos have a way of corrupting themselves almost irreparably. On Ubuntu (Debian based) if things go wrong I've always been able to run a few commands and get things nice and stable again.
  - mergy 13y ago
    Indeed.
- ams6110 13y ago
  My impression is that they got a bad rep long ago before there were decent package managers. As I recall, you had to install dependencies manually and updating a system could get nightmarish. Nothing really wrong with rpm as a package technology per-se, but before yum it was a lot less friendly.
  - Shish2k 13y ago
    Just a couple of days ago I was doing an upgrade from 6.4 to 6.5 and yum died in the middle; fixing that was quite hellish as rpm somehow decided that multiple conflicting versions of several packages were installed at once (eg glibc v131 and v137), and it wouldn't do anything until that was fixed (it wouldn't even attempt to fix the problem until it was fixed... "yum-complete-transaction" just complained about things being inconsistent and wouldn't roll back or forwards - "transaction" my arse). Ended up fiddling with "rpm --no-deps" to fix individual packages after drawing out the dependency graph by hand :( I've had problems with individual .deb packages before, but never broke the whole package management system quite like that before :P
    - mergy 13y ago
      Right. RPM can get hosed pretty easily.
SwellJoe 13y ago
Just to provide a similarly brief and pointless argument: I strongly prefer yum/RPM to apt-get/deb, both as a package maintainer (for tens of thousands of users) and as a system maintainer with dozens of servers to maintain.
- mergy 13y ago
  Not my experience. I hope it has improved, but the missing dependencies were always a total pain.
  - SwellJoe 13y ago
    Both yum and apt-get have excellent dependency resolution. I don't really know what else to say about it. I can remember the days of "RPM hell" (though I rarely found it all that problematic) as I've been using Linux as my primary server and desktop OS since 1995, but yum was in widespread use by 2005. It's been a long time since missing dependencies was a thing you needed to think about on any modern Linux distribution. My preference stems from the following: 1. yum repos are so simple to create and maintain! One command, one directory, no files except the packages themselves. Contrast this with apt-get...it literally took me weeks to figure out how to create an apt-get repo. It requires several configuration files, which are generally human maintained (as far as I can tell, the docs for maintaining a repo separate from the Debian repo are awful and leave more than half of the process out completely, to be guessed and googled...they assume you only want to add a package to the Debian repo, not create a new one). It is also inefficient as hell. Generating our Debian/Ubuntu repo meta-data takes an order of magnitude longer than the yum repos. 2. Packaging RPM is much nicer, IMHO. If you don't need patches, it's just one file, the package-name.spec, plus the tarball. If it's a standard "./configure; make; make install" process, your spec file can be almost empty. The spec file is well-documented (Epoch is tricky, and a couple of the macros aren't immediately obvious, but in general, I can answer my questions by reading the docs). Debian requires several directories full of files for every package, and the documentation is obtuse. Again, it took me a long time to figure out how to package for Debian, and there's no good source for what tools you use to create and maintain packages. Wanna sign those packages or repos? Good luck! There are three or four different ways documented, and it was not at all clear which was the right way. I had to dig into the Debian repos to see how they did it, and try to replicate it. I think I'm doing it right. 3. As a user, I dislike apt-gets tendency to want to remove packages based on dependencies no longer existing...so, if Apache were installed to satisfy a dependency in another package, and you remove that other package, apt-get will (with some configurations, seemingly the default) ask if you want to remove Apache. Even if you have a hundred VirtualHosts configured and rely on Apache for everything! I find some of apt-gets other defaults alarming. 4. yum has mock. mock is amazing. Building packages for any RPM/yum-based distro with one command and one configuration file (and maybe a custom repo, if there isn't already one) is so awesome. As a package maintainer, this would be enough to win my heart forever. apt-get has some kind of fake root thing, or something, but I can't figure it out, so I have to maintain a VM for every Debian/Ubuntu version we support. This sucks and is tedious as hell. But, if I had to live with apt-get, I certainly could. They are, honestly, both amazingly great technology, and I can't imagine life without a good package manager. I hate Windows and Mac for this very reason. I can't believe people think Mac OS X is acceptable, given the awfulness of package management on the platform. Even Windows has better package management than Mac OS X. Some amazing things about both: yum has groupinstall and apt-get has tasks. Super cool! Install a huge swath of packages, for achieving a specific goal (like "Development Tools" or "Gnome Desktop") with one command. Brilliant. Easily install all the dependencies you need to build a source package, based on it's specified build dependencies. How amazing is that? Not only can you install the source code and the config files, patches, and data files you need to replicate the package from source, you can also replicate the needed build environment easily. (Add mock on yum-based systems, and you have packager heaven.)
mergy 13y ago
Always nice to get -4 on a comment harshing RPM. HN folks are nutty.

Now if they can just get rid of RPM I might come back!

by mergy 13y ago

Now if they can just get rid of RPM I might come back!

Nux 13y ago

Do come back, it's better than the competition nowadays. :)

BCM43 13y ago
How so?
- undoware 13y ago
  I'm not sure what the OP 'mergy' intended, but I'd guess that the intended reason had to do with better ecosystem curation. Under the hood, my understanding is that .rpm is marginally inferior to .dpkg, but not remarkably so. E.g. using cpio instead of gz as the format basis. So by elimination, the only reason to prefer .rpm would be the rpms, if you follow. As a longtime Fedora user and a recent emigre (post-Snowden) to OpenSuSE, I agree that there is much to love about the selection of RPMs available, especially under Fedora. Although I'm sticking with suse for the lightning-fast zypper (still noticably faster than yum or even its slated nextgen replacement dnf!) and well-thought-out snapper utilities. But that is OT.
  - matt__rose 13y ago
    Mostly it's a matter of picking your poison. dpkg allows some things that RPM doesn't, and vice-versa. dpkg does have some nice features (well, features I can't remember, except for I went "Ooo, I want rpm to have that" when I saw it) One thing that dpkg has that really annoys the hell out of me is allowing for user input during the transaction. It makes unattended upgrades impossible
    - YokoZar 13y ago
      In general Debian/Ubuntu packages do not prompt the user with debconf questions these days, although there are occasional leftovers in old packages if you upgrade via a terminal with apt-get update. You can define an environment variable, DEBIAN_FRONTEND=noninteractive, to force even the worst-behaved packages to never ask a question.
      - tene 13y ago
        You can set those configurations, certainly, but it's up to the package maintainer to actually respect them. At my previous company, I occasionally ran into packages that insisted on trying to read from the terminal, even when installed noninteractively, with all configuration flags set to noninteractive. I can understand the potential appeal for a lone individual working with a small number of hand-maintained systems, but when working with a large cluster, interaction during package operations is just a horrible misfeature.
mergy 13y ago
It's been years, but RPM was always frustrating compared to the ease of apt.

ciupicri 13y ago

What's wrong with RPM?

jebblue 13y ago
For me in past years on Red Hat, Fedora and SuSE the RPM repos have a way of corrupting themselves almost irreparably. On Ubuntu (Debian based) if things go wrong I've always been able to run a few commands and get things nice and stable again.
- mergy 13y ago
  Indeed.
ams6110 13y ago
My impression is that they got a bad rep long ago before there were decent package managers. As I recall, you had to install dependencies manually and updating a system could get nightmarish. Nothing really wrong with rpm as a package technology per-se, but before yum it was a lot less friendly.
- Shish2k 13y ago
  Just a couple of days ago I was doing an upgrade from 6.4 to 6.5 and yum died in the middle; fixing that was quite hellish as rpm somehow decided that multiple conflicting versions of several packages were installed at once (eg glibc v131 and v137), and it wouldn't do anything until that was fixed (it wouldn't even attempt to fix the problem until it was fixed... "yum-complete-transaction" just complained about things being inconsistent and wouldn't roll back or forwards - "transaction" my arse). Ended up fiddling with "rpm --no-deps" to fix individual packages after drawing out the dependency graph by hand :( I've had problems with individual .deb packages before, but never broke the whole package management system quite like that before :P
  - mergy 13y ago
    Right. RPM can get hosed pretty easily.

SwellJoe 13y ago

Just to provide a similarly brief and pointless argument: I strongly prefer yum/RPM to apt-get/deb, both as a package maintainer (for tens of thousands of users) and as a system maintainer with dozens of servers to maintain.

mergy 13y ago
Not my experience. I hope it has improved, but the missing dependencies were always a total pain.
- SwellJoe 13y ago
  Both yum and apt-get have excellent dependency resolution. I don't really know what else to say about it. I can remember the days of "RPM hell" (though I rarely found it all that problematic) as I've been using Linux as my primary server and desktop OS since 1995, but yum was in widespread use by 2005. It's been a long time since missing dependencies was a thing you needed to think about on any modern Linux distribution. My preference stems from the following: 1. yum repos are so simple to create and maintain! One command, one directory, no files except the packages themselves. Contrast this with apt-get...it literally took me weeks to figure out how to create an apt-get repo. It requires several configuration files, which are generally human maintained (as far as I can tell, the docs for maintaining a repo separate from the Debian repo are awful and leave more than half of the process out completely, to be guessed and googled...they assume you only want to add a package to the Debian repo, not create a new one). It is also inefficient as hell. Generating our Debian/Ubuntu repo meta-data takes an order of magnitude longer than the yum repos. 2. Packaging RPM is much nicer, IMHO. If you don't need patches, it's just one file, the package-name.spec, plus the tarball. If it's a standard "./configure; make; make install" process, your spec file can be almost empty. The spec file is well-documented (Epoch is tricky, and a couple of the macros aren't immediately obvious, but in general, I can answer my questions by reading the docs). Debian requires several directories full of files for every package, and the documentation is obtuse. Again, it took me a long time to figure out how to package for Debian, and there's no good source for what tools you use to create and maintain packages. Wanna sign those packages or repos? Good luck! There are three or four different ways documented, and it was not at all clear which was the right way. I had to dig into the Debian repos to see how they did it, and try to replicate it. I think I'm doing it right. 3. As a user, I dislike apt-gets tendency to want to remove packages based on dependencies no longer existing...so, if Apache were installed to satisfy a dependency in another package, and you remove that other package, apt-get will (with some configurations, seemingly the default) ask if you want to remove Apache. Even if you have a hundred VirtualHosts configured and rely on Apache for everything! I find some of apt-gets other defaults alarming. 4. yum has mock. mock is amazing. Building packages for any RPM/yum-based distro with one command and one configuration file (and maybe a custom repo, if there isn't already one) is so awesome. As a package maintainer, this would be enough to win my heart forever. apt-get has some kind of fake root thing, or something, but I can't figure it out, so I have to maintain a VM for every Debian/Ubuntu version we support. This sucks and is tedious as hell. But, if I had to live with apt-get, I certainly could. They are, honestly, both amazingly great technology, and I can't imagine life without a good package manager. I hate Windows and Mac for this very reason. I can't believe people think Mac OS X is acceptable, given the awfulness of package management on the platform. Even Windows has better package management than Mac OS X. Some amazing things about both: yum has groupinstall and apt-get has tasks. Super cool! Install a huge swath of packages, for achieving a specific goal (like "Development Tools" or "Gnome Desktop") with one command. Brilliant. Easily install all the dependencies you need to build a source package, based on it's specified build dependencies. How amazing is that? Not only can you install the source code and the config files, patches, and data files you need to replicate the package from source, you can also replicate the needed build environment easily. (Add mock on yum-based systems, and you have packager heaven.)

mergy 13y ago

Always nice to get -4 on a comment harshing RPM. HN folks are nutty.