Hello,
Well I just heard a couple of guys saying "rpm hell".
Now a days, when rpm works very well, still does it lag behind apt in some ways...?
Thanks.
On 11/21/2013 10:29 AM, AP wrote:
Well I just heard a couple of guys saying "rpm hell".
Now a days, when rpm works very well, still does it lag behind apt in some ways...?
yum didn't always exist. yum handles the dependencies between packages. Before that, a lot of prayer was involved if you mixed rpm packages from different sources.
- Mike
On Thu, 2013-11-21 at 20:59 +0530, AP wrote:
Well I just heard a couple of guys saying "rpm hell".
Probably a reference to the very early days of RPM (pre-yum). You'd install a package, then find some library was missing and go to install that, which led to something else missing, etc. A few cycles of this and you know what "dependency hell" means. Nowadays, with yum, all the dependencies are pulled in automatically, so "rpm hell" is largely a thing of the past.
--Greg
On Thu, Nov 21, 2013 at 4:51 PM, Greg Woods woods@ucar.edu wrote:
Probably a reference to the very early days of RPM (pre-yum). You'd install a package, then find some library was missing and go to install that, which led to something else missing, etc. A few cycles of this and you know what "dependency hell" means. Nowadays, with yum, all the dependencies are pulled in automatically, so "rpm hell" is largely a thing of the past.
Sort of. RPM was a victim of its own success. Because Red Hat was the leading distribution, it was the one that attracted the largest number of third party RPMs, and that's what caused the dependency problems that came to be known as RPM hell. Also, people would mix RPMs from Red Hat, SuSE and other distributions and just expect them to work (which largely they didn't). That problem still exists today, exactly the same as it does for dpkg based distributions (and always has done). It's just that the RPM and dkpg repositories these days have larger coverage of the free software landscape, so the dependencies are more likely to be in the default repo, and there are fewer third party packages these days, as well as fewer RPM based distributions to muddy the waters.
Tet
On Thu, 21 Nov 2013 17:01:24 +0000, Tethys wrote:
On Thu, Nov 21, 2013 at 4:51 PM, Greg Woods woods@ucar.edu wrote:
[....]so "rpm hell" is largely a thing of the past.
Sort of. RPM was a victim of its own success. Because Red Hat was the leading distribution, it was the one that attracted the largest number of third party RPMs, and that's what caused the dependency problems that came to be known as RPM hell. Also, people would mix RPMs from Red Hat, SuSE and other distributions and just expect them to work (which largely they didn't). That problem still exists today, exactly the same as it does for dpkg based distributions (and always has done). It's just that the RPM and dkpg repositories these days have larger coverage of the free software landscape, so the dependencies are more likely to be in the default repo, and there are fewer third party packages these days, as well as fewer RPM based distributions to muddy the waters.
It can still happen in another way, to those who use free but proprietary apps.
Say you want Opera on an old machine that you haven't used for some time. You go to a browser it does have, but for some reason the default opera.com offers isn't what you want. You find what you do want, and opera.com asks whether you want the x86 or the 64-wide version.
You don't happen to remember which one this machine is, nor an easy way to check (like uname -a). So you just download one.
Rpm -ivh produces a bramble patch.
Being by now an old hand, you notice that all the missing dependencies it announces are 64s. So you abort the install, go back to opera.com, and get the .rpm for a 32-bit machine. That works, slick as a whistle.
In this example you have not solved the dependency hell. You have dodged it, partly by dumb luck (spotting those 64s), and partly by having enough general experience to recognize what they mean.
A beginner who had gotten into it might easily've worked herself through the brambles into an electronic lake of burning brimstone before she hollered for help.
-
AP -
Beartooth -
Dr. Michael J. Chudobiak -
Greg Woods -
Heinz Diehl -
Tethys