I've been up late (late) the last few daze trying to sort out a few things. My latest thing is trying to figure out this rpm/dependency hell stuff. Now, i'm not speaking of simply having to chase all over creation to find libraries and wot not that your program X may need. I assume most pkg mgrs can at least handle that part.

More specifically, the problem i'm trying to figure out is this (taken from this essay on "RPM Hell" ) :

"Eventually, if you're lucky, you get the software installed. More commonly, you've broken some other piece of your system -- "A" depends on "B" version 2, but "C" depends on "B" version 1, and there isn't a newer version of "C" that is happy with "B" version 2. You have to choose between "A" and "C". Even more commonly, you find yourself installing software that you never wanted or needed, but is a required install because of a bad dependency tree. "A", a purely text-based application, depends on "B", which depends on "C", which depends on "D", which depends on X11. "

What I've been able to gather is that somehow, someway compiling from source does away with this problem of dependency hell. I'm quite sure it's due to my appaling ignorance of how OSes work, but I don't get it. If I'm compiling a program, will it not still have (at least usually) the same dependencies?? How do the source-based distros get around this problem?

Is the only way for binary-based distros to get around it is to allow for multiple versions (not that I have a deep problem with that)

Optional Blather:
I know there are a few threads in here started by some folk who're quite frustrated by this (and related) phenomena. Seems like there've been a _lot_ of ppl who've skipped joyfully into Linux land and after a period of time, mebbe 6mths, mebbe a year or two, find themselves utterly frustrated by conundrums that by and large were rare(r) problems in M$ land.

Now, don't get me wrong, I'm committed to sticking it out (ok, i kinda hafta at this point as i've completely wiped win98 off my sys), but i'm trying to look ahead and, where i can, dodge PITA issues way in advance.

Anyway, my eyes are growing dim with all this reading (and rereading). Probably overthinking myself into these knots, but I'm pretty sure (knock wood) this' the last major issue I'll deal with before I finally settle on my distro-for-the-first-year.

Mandrake has urpmi
RedHat/Fedora have apt-get and yum
Slackware has swaret and slapt-get
Debian oses have apt-get

These package managers all resolve dependencies when they download the package and you don't have to switch distros (the essay mentions portage which afaik isn't a Mandrake or RedHat package manager).

They do, but to a lesser extent... chances are that,
for instance, a program will be just as happy with
openssl-0.9.7.3c as it was with 0.9.7.1, but RPM
will be a bitch and insist on the EXACT version.
Sure, you can override that, but then you have
"broken dependencies" by the truckload.

There are (and probably always will be) things that
are impossible to solve, but you will have to resolve
that manually ...


Cheers,
Tink

yes, like tink said, binary formats are expecting an environment exactly like it was when it was compiled, so if versions arnt exact, they will not work.

i don't use package manages, and just compile form source only (cause i want it made for my system), and iv never had dependency issues like those. at worst is a program depends on another program that depends on this, usually tho other programs also use the same dependencies, and these are all part of any distro (like m4, and if it has a GUI, then the xlibs),

almost any dependency issue with source code is easily fixed as its only a matter of getting the missing lib or program and compiling that, and looking at the requirement's page (if there is one) when you download source codes..

altho there are some hard to find packages (actually they are easy to find if you want .rpm , but a pain to find the sources to them)

Thanks Tink and Xavier -- I _think_ wot you're saying is that the terms "rpm hell" and "dependency hell" are interchangeable? That is, you only get dependency hell if you use only rpm pkgs (w/o a pkg mgr). Is that right?

My bad. I thought you could/did still run into dependency hell issues even using apt-get et al. Well that's all a big relief.

Ok, well that makes things tuffer then cuz instead of cutting off one side or the other (source-based vs. binary-based), i have the whole smorgasboard of distros from which to choose.

Ah, now, which iso...which iso...?

SciYro, thank you so very much. that one sentence made it all clear as day for me now.

Cheers!

Oh, waitaminit. I got ahead of myself. Though SciYro's reply clears up a lot for me, I'm still not sure it solves the catch-22 dilema posed originally.

I get that usually you can get by with the existing libraries already installed (or that often the new version is backwards compatible), but isn't it simply one way or the other -- ie. either A depends or B or it doesn't? Isn't the binary just saving me the step of compiling the code? In other words, isn't it set up somewhere in the source code that A requires B?

And another thing: Do these apt-get etc managers solve those issues for you by creating diff versions automatically then?

the various apt-gets and their siblings will download and install the packages, they also do a dependency check and resolve the dependencies for you.

yeah from the moment i installed libranet 2.8 which is based on debian i forgot about dependency hell and all of that.

when i want to install a program i just enter apt-get install <program name> then it will download it and install it for me and if there are dependency then it tells me that it will download or upgrade other packages.

Ok, thanks guys. I think my brain just overheated. I let it cool down. I will trust and obey ;-)

Cheers!

I'm running slackware with swaret, and it's working like magic medisin to my system.
Just hit swaret --update, and it will check my entire system and do the nesseccary updates.

If you are talking rpm's, try using the --aid switch. It might be old, but it still works. It will check for dependancies and install the right stuff.

Well, remember folks, that the heart of this particular bug-bear wasn't so much the ability of a pkg mgr to find/install/track the dependencies for you, so much as resolving potential conflicts.

like, if the new version of pkg Y (which pkg X, wot you're really after, requires) breaks already pre-existing pkg Z (which uses the old version of pkg Y), then wot?

i will assume from all you guys are saying (and mainly cuz i'm tired of thinking aobut this now ;-)) is that these nifty smart pkg mgrs will figure out all that mess for you. n'est pas?

If you stick with packages provided by one vendor then this is very unlikely to happen. If the situation you describe above occurs then the package manager will complain that the older version of Y is required by Z, and it'll probably either remove Z or hold back X.
This is where a source based distro, such as Gentoo, comes in handy. Chances are package Z will work properly when its compiled against the new version of Y. If it does not, usually what I do is I go check out Gentoo bugzilla and forums, you'll probably find half a dozen people having the same problem and if you're lucky, someone will provide a solution (like a patch or workaround).

Thanks muchly Demonbane. You've explained this in a way that I can unnerstand it (i think). So my next question is, is it possible to have two versions of Z on my sys at the same time? Can I have two versions of Y on my system at the same time?

That is, I'd have the (pre)existing Z, then I might compile Z fresh against the new Y (somehow?). If the compiled Z worked fine, then I could delete the original and the old Y. THEN I could go ahead and install X, no prob.

Is that possible to do? Is it super unadvisable to do (something akin to logging in as root by default)?

Cheers again