APT - With Your Favorite Distribution 386
Then there is another solution from Connectiva in Brazil, which has made something called APT4RPM -- basically an APT wrapper around RPM database on your machines, so you can use all of Debian's APT features (sans DSELECT feature) to upgrade your packages, or your entire distribution. (So now you can use your favorite distribution AND APT to update it.)
Two open source developers have improved Connectiva's solution to work with ANY RPM-4 based solution, and the [not finished yet but seems pretty stable solution] is at APT4RPM project pages in sourceforge. I have decided to give a test on my Redhat 7.2 machine. I installed the binaries, edited the /etc/apt/sources.list (just remove the # from your distribution's mirror), typed "apt-get dist-update," crossed my fingers -- and lo and behold, 48 new packages were installed, 7 were upgraded, and I only had to press "enter" to start the ball rolling!
So, for those of you who want to test it -- the URL is above (and if you could help with creating mirrors for your favorite distribution - that would be very helpful, thank you), you might want to try it. Just don't forget to read the FAQ before doing anything, and report bugs to the authors. Note: although the binaries are for Red Hat, the SRPMS are right there so you can just recompile it on your favorite distribution. Enjoy.
rpm (Score:5, Funny)
Re:Is your son obsessed with "Lunix"? (Score:3, Funny)
that was bizarre and hilarious
Unsolvable problems (Score:4, Insightful)
I don't see any problem here, either. All the dependency "problems" I can imagine can easily be solved by a flatrate, some time and a big harddisk.
On SuSE, I often used --nodeps for rpm, cos I *knew* that mutt doesn't *require* a spell checker, even if the stupid
I've Said It Before: Debian is more than apt (Score:5, Insightful)
Sure, dependency problems happen, but far less often than I ever had to deal with in Mandrake or Redhat, and when they do happen they are fixed very quickly. How many times have I seen in the unstable changelogs on entirely new package uploads with the only change being some minor dependency problem which hadn't affected me?
The fact is, Debian's social structure is what gives it its power, not the tool it uses. While apt is a powerful piece of work, it's the community that gives Debian that special glow that all these other distros are trying to emulate.
To complete your analysis... (Score:2, Insightful)
In recent years, it's almost like someone went through, spanked all the naughty package maintainers, and told them to behave. And they did. And now Debian is really reaching its true potential.
I have watched it happen. After using RedHat for a couple years, a friend of mine finally convinced me to try Debian, and so I installed it one day after RedHat pissed me off for the n-millionth time with its own stupid broken packages. The install was a bitch and a half, and I had to install three times to get a usable system, but it's like riding a bike - once you do it right, you never forget. Debian is getting a new installer soon anyway, but I digress. The packages were mostly OK, but there were a few that just hosed everything else by nature of fucked up dependencies. Netscape was particularly prone to this in the unstable tree, but there were others as well in both stable and unstable trees. That was in '99.
Now it is almost 2002, and Debian has been devoid of these fuckups for a good year and a half, from what I've seen. Stable is *stable,* man, I mean like a rock! Even unstable is good. I raaaarely run into anything that's broken even in that branch!
If you used Debian before and threw up your hands in defeat because of fucked up packages, give it another try! It is *much* better now.
Re:Unsolvable problems (Score:3, Insightful)
I did this too, back when I was using Red Hat. Sometimes it was the only way. In the end, I said "to hell with the database" and started building everything from source tarballs.
Things went fine, and my what was originally RH 6.0 install soon became more advanced and up-to-date than RH 7.0
Anyhow, to make a long story short, I decided to install Debian woody. I ordered the CD set from the computerhelperguy [chguy.net] who, at that time, was the only source for woody. I EFT'd $20 bucks and, about a week later received the 5-CD set.
Switching from RH to Debian imposed a significant learning curve, but APT is schweeeeet, and I don't think I'll be going back anytime soon.
Now that the intro material is out of the way, anybody and everybody who uses an rpm-based distro, owes it to themselves to try out apt4rpm. The beauty of apt is that it automagically resolves all the dependencies, and in those cases where you get circular dependencies, it picks what appears to be the least damaging package to apply the --nodeps option to.
I'm not saying that Debian is the best distro. I am not distro-religious. I am not anti-rpm, although I would like them use
Try it
Re:Unsolvable problems (Score:3, Insightful)
Conflict 1 of 9:
Package (some package) is incompatable with existing package. (or needs some other package, whatever.)
a. Remove other package.
b. Install additional package. (from other dist source)
c. Only install relevant part of package.
d. Do not install this package.
Some see this as an annoying feature, but once you understand how it works, you just don't get bad installs any more. Until you are smart enough to break the rules, the system won't let you perform an incompatable install. (We need this feature in the open operating systems!)
The point here is that the user makes all the choices up front before anything hits the filesystem. The way this system currently works, the user can know very little yet still get a good install. May not be exactly what they had in mind, but their system is still around for them to learn and make that second try.
The only area this system is lacking is in the net awareness area. Currently works with local or local networked media.
You are right though about the other managers out there. If I had to choose, I would currently choose apt or perhaps pkg_add because they are net-aware, and work the best because the social structure around them encourages good thoughful packaging.
Re:Unsolvable problems (Score:4, Insightful)
Some points:
If you have the brains to compile from source, you have the brains to write a spec file. Its not hard.
APT is not a packaging system, and never was. Its an application that sits on top of packaging systems. APT designers have repeatedly stated they designed APT to be independent of packaging systems. If APT running on Red Hat is a `hack' then APT is general must be if the authors designed it with such functionality in mind...
I have a box here running CVS versions of every GNOME package, up to the moment KDE, and every other package I want - 873 in total, same install for around a year upgraded between versions since 7.0. 873 packages, no problems with dependency hell, and not a single package is installed without its dependencies being met.
Have you every considered that RPM:
a) Might have changed since you last looked at it?
b) May have a wide variety of utils (as mentioned in the cover story) that can do everything PAT does?
c) Might take time to learn. Which is a problem, since Red Hat generally tries to be more friendly about most things. But just as when I sit down on a Debian box and have to know a bunch of stuff about which module to use for a given hardware component (something Red Hat's kudzu neatly avoids), when I sit down on a Red Hat box I have to know a little more about packages - those tools might exist, but they're not part of culture of the OS yet.
Might be easier to learn if you researched it rather than made up thinsg about it. RPMs can provide/require library versions or the names of other packages - a poster below is trying to make out that's not the case and making a fool of himself by basing his little rant on it.
RPM can do some very handy stuff that DEB can't - like verify packages, have a transaction based installation system, and allow the default compile of a distros DVD player to be, shock horror, pentium and up only. In turn, APT can do things up2date can't, mainly because of some smart policy decisions on the Debian teams behalf and a whole bunch of nice apps available to download (as the person above pointed out). Neither is perfect, not by a long shot, and there's many other considerations when choosing a distro.
And finally: RPM is the Linux Standard Base method of installing software. Yes, alien can do them on Debian, no it can't do this well. In two years time, this will start hurting distros that aren't LSB compliant. Which means Red Hat will reverse the
Re:Unsolvable problems (Score:2)
We're committed to using Alien for this. The LSB was designed with that in mine. If it had been a matter of the LSB requiring us to change to RPM, Debian would have probably left.
Re:rpm and dpkg package verification.... (Score:3, Informative)
I believe that RPM packages always have md5 checksums on all the files, whereas .deb packages, by default, do not.
That's probably what you heard.
Re:Unsolvable problems (Score:2, Informative)
This is why Debian has fiels called 'Recommends' and 'Suggests'. However, apt doesn't honor these, other frontends do (like aptitude)
Package: mutt
Depends: libc6, libsasl7, exim | mail-transport-agent
Recommends: mime-support
Suggests: locales, urlview, ispell, gnupg | pgp | pgp5i
apt won't install ispell, but other aptitude will tell you that those packages are suggested or recommended by the package maintainer.
Re:Unsolvable problems (Score:2, Funny)
and obviously it's not easily solved.
I did a potato install for a friend yesterday, and upgraded to woody.
Thank god apt didn't spit out all suggested packages when I did the dist-upgrade !
The xterm would have run out of ink !
Best solution would probably be:
1. run dselect-upgrade for upgrades, even if it's a bit enthusiastic with removing stuff
2. actually *look* (gasp!) at the package's description when doing an apt-get install
3. use Clippy(tm) ! Something like:
"I see you're installing libfoo.
To get a better foo experience, I could install libbar for you !
(Note: you need to be registered at DebianPassPort)
"
;-)
Um (Score:3, Interesting)
the posibilities (Score:2, Funny)
Where's the aspirin? (Score:3, Funny)
run slackware (Score:4, Informative)
This was one of the reasons I moved to slackware. Virtually no package management. You want software? Get the darn tarball and have at it. Configure will tell you if you don't have the right dependencies. It has worked wonderfully for me. Yes, I know of the disadvantages of slackware's lack of package management. They are smaller than the advantages, imho.
On that note, I think since Slackware pretty much starts at nothing in the PM arena, it would be a great candidate for some kind of apt-get-type system. But that would, after all, pretty much collide with slackware's motto of being kept exceedingly simple. (Almost to a fault, some might say.)
Re:run slackware (Score:4, Informative)
Ever check the contents of files in
Go to linuxmafia.org, download the latest package for say, kde-2.2.1 since you see no reason to compile it yourself, and use the installpkg command, ie: "installpkg kdelibs-2.2.1.tgz".
Then go check the contents of
Want to get rid of a package you don't need anymore? "removepkg kdelibs-2.2.1" will do the trick. If there's a file in kdelibs-2.2.1 that any other package in
Want some sort of crappy gui to use for messing with packages? "pkgtool" allows you to install packages, remove packages that are already installed, and view package contents, while being slightly more friendly than having to grep each package file or opening all of them in your favorite text editor (vi, of course).
Simple package management at its best.
Slackware's priorities... (Score:3, Informative)
Further down in this thread, someone mentioned the
Everyone makes a big deal about compiling from source in Slackware, or "not having a package management system", but completely ovelook the reasons why slackware doesn't appear to focus on package management.
forgive me if i've repeated myself a thousand times. i'm just ranting.
My take on it. (Score:5, Insightful)
Anyways, to my main point. You're *still* going to have dependency problems. This isn't a magic wand. It works well in Debian because a) there are hundreds of mirrors, they all carry the exact same packages, and they're all administered with a decent degree of competence. And b), the Debian packagers *care*. The packages install so easily because, generally speaking, Debian Developers arn't lazy. In fact, following the Debian Policy(a big reason why packages under Debian install and work so well) is actually kind of a pain in the ass. But it's still followed.
Yeah, apt-get is great. But it's just a tool to deal with packages. If the packages it's dealing with are crap, then it won't help you one lick. Most Debian Developers take care of a *single* package. There is a decent minority that takes care of a number of packages each, and there are a very very few that take care of dozens of packages each. And these people *use* their packages; they use the apps they package, they use Debian, they use their Debian packages.
Can you say all that about Red Hat? How many thousands of packages do they have, and how many package maintainers? A few dozen? Full-time? That's being optimistic. You're still looking at a stunning lack of man-power(when compared with the alternatives).
Re:My take on it. (Score:3, Informative)
What? How do you know?
This one's pretty easy. The maintainers' names are plastered all over the place and there are easy referencing methods. He's mostly right, though I think the norm might be something like two or three packages.
"the Debian packagers *care*"
Really? More than people who make rpms? How much more do they care?
This is subjective, but it's very easy to get in tough directly with the maintainers, who usually listen to your problems.
Re:My take on it. (Score:2, Informative)
>What? How do you know?
You can find out who maintains how many packages here: List [debian.gr.jp]
statistics (Score:3, Interesting)
First 21 maintainer takes care of 30 sources packages or more, for a total of maybe 1000 (sources) packs. 144 maintainers care about >=10 source packs etc.
Now let's go and look at the bottom of the list:
270 maintainers with 1 pack
141 maintainer with 2 packs
...
While this is a great thing to have, the fact remains that it's the "top 50", or maybe "top 100" who make the most of the stuff, and each of these has a fair number of packs to do. Not that much different from commercial distros.
Re:My take on it. (Score:3, Informative)
I have three packages in Debian that I am personally responsible for. I'm very familiar with each of those packages, in a way that no one that packages a hundred packages can be. I'm also very responsible for each of those messages - Debian has a tracking system [debian.org] for bonehead mistakes (and other things) that I like to keep clean. Almost no RPM developers have that combination, and it functions the same way for many of my fellow developers.
Red Hat -> Debian via Connectiva apt (Score:5, Funny)
Back in August I decided to give Debian a try. I downloaded the apt and dpkg SRPMs from Connectiva and installed them on my Red Hat 7.0 system. It took a bit of shoe horning to get them in, but I made it happen and they worked.
Then I went into the /etc/apt directory and pointed everything at the Debian archives instead of Connectiva. At first I tried to just aim it at ftp.redhat.com and update my 7.0 install, but apt and the Red Hat archive didn't like each other. Anyway, I ran apt-get update and got the Debian lists, then was able (with a lot of manual this-and-that that I really should have documented) to apt-get dist-upgrade into Debian stable without rebooting.
Since I was dialing up at the time, it took a while, like a week or so, just to download it all. Once I got everything installed, I let it run for a while for shits and giggles. For a period of almost a month, I had a couple of virtual consoles logged in, a couple displaying Debian's /etc/issue and a couple displaying Red Hat's /etc/issue. Then I decided to do the kernel, too, and rebooted.
I'm still finding a bit of Red Hat cruft now and then. Oh well.
Re:Red Hat - Debian via Connectiva apt (Score:2)
Re:Red Hat - Debian via Connectiva apt (Score:2)
Maybe it was (Po)lished Linux then, I don't recall. Either way, I got an apt and a dpkg RPM and went from there.
Afraid to use auto-updaters (Score:2, Insightful)
So I'd end up with C:\DOS, C:\APPS, C:\GAMES, and C:\P0R... umm.. forget that last one.
I guess I just have a thing for knowing exactly what is on my system. Waste not, want not. I still remember having to carefully pick and choose to get what I wanted on my 1.2MB drive. Most distributions seem to treat harddrive space like water. All this in the name of compatability?
Back to my original point, about not liking updaters... I don't like the abstraction of chooing an app and letting it install it's dependancies itself. Yeah, that's a nice thing (and probably the best for the end users) but why can't I just have a nice page saying something like: "you need these packages to [install|use|have sex with] this package"?
Meh. I'm probably too anal retentavie on this issue, but when I look at the filesystem I do not want to be saying "what the hell is that?".
I guess I've been burned one too many times by updaters that accidently install older modules over newer ones simply because it didn't "know" better.
Incedently, I really like the Windows XP driver protection thing. To sum it up, if you attempt to install a non-certified driver, a dialog essentially tells you that 'installing this driver may f**k up your computer. Install anyway?" (Am I the _only_ one who thinks that this was the original, developer, text for that dialog? hehe.)
Nevermind me, I'm just an incoherant babbling idiot. Move along.
Re:Afraid to use auto-updaters (Score:2)
Re:Afraid to use auto-updaters (Score:2)
But, then again, maybe all this isn't necessary. When you have libraries named "libksysguardapplet" and "libevolution-importer", they sorta speak for themselves.
Re:Afraid to use auto-updaters (Score:2)
As another poster already pointed out, there are too many packages on a typical Linux system for one person to keep track of. On my computer I have just over 1000 packages installed.
>> I guess I just have a thing for knowing exactly what is on my system.
That's exactly why you should use package management. There is no way someone can keep track of over 1000 packages for even something like 7 years. If you are an employee you might not still be around in 7 years.
>> why can't I just have a nice page saying something like: "you need these packages to [install|use|have sex with] this package?
If you use debian, already do.
>> I'm probably too anal retentavie on this issue, but when I look at the filesystem I do not want to be saying "what the hell is that?"
Not too anal retentive at all. Here again package management is the solution to your problem.
Pretend I don't know what package installs zipsplit.
Ah... zip installs zipsplit.
>> I guess I've been burned one too many times by updaters that accidently install older modules over newer ones simply because it didn't "know" better.
Apt-get allways tells you what is going to be installed.
If you don't want to install the other packages just type 'n'.
Also when debian changes a config file it always shows you the change and asks you if you want to do it. I sometimes am not sure and make a backup of the original just in case.
The really good thing is that debian stores the old copies for you in
Package management is nice for new users, but more importantly, it is good for people who don't want to reinstall their operating system every 5 years.
that's missing the point (Score:5, Insightful)
Rpm is getting a bad rap because it is actually a bit more flexible in practice: because it uses file dependencies extensively, you can, in fact, install rpm packages on systems even if you don't have a whole dependency infrastructure built around them or if some of the files come from manual installations. That's why so many more RPM packages are distributed on people's web sites than Debian packages. But this comes at a cost: as people try to do more (uncoordinated packaging), more things can go wrong. Some of the combinations you might want to install are simply impossible. With apt, you wouldn't even try because it's not a choice. With rpm, you can try but it fails, and rpm is then blamed for the failure.
If you could build an infrastructure like the Debian project around rpm, I expect it would do just as well as the apt/deb mechanism (the automatic download managers already exist).
I use mostly apt/deb right now, but I have also used rpm a lot in the past. Altogether, I think neither rpm nor deb/apt have really solved the packaging and system update problem completely yet. They are both rather imperfect solutions, each with their own advantages and disadvantages.
YOU (Score:2)
YOU == YAST Online Update
Unified BSD packaging thingie? (Score:2)
Re:Unified BSD packaging thingie? (Score:2, Informative)
What apt is about... (Score:4, Informative)
It's cool because
1. For debian testing/unstable you can get daily updates to your system. For stable you can get daily security updates.
2. You know updating your system will be a simple, painless and easy process. You know it will automagically work after two shell commands.
3. It is much more configurable than most RPM interfaces.
4. There is usually one "kind" of debs, which come officially from Debian.org, instead of a million different RPMS for Redhat/Mandrake/SuSE etc which conflict with each other
5. You have almost everything you need. If you use "unstable", you will always be on the "bleeding edge" with not too many problems, rather than waiting for distros to release their latest CD, and then sometimes trash the whole system because of a failed upgrade.
6. And of course, without the dependency hell!
As you see, dependency hell isn't the whole reason why people prefer apt above RPM based systems. Before they solve these problems, debian/apt will still be my first choice.
48? Ouch... (Score:2)
Question: I want to update my KDE (from the default Redhat 7.2 distro) and I've never had success when I've tried downloading all the rpms manually and trying to solve the #&#*@ dependencies...as a new user of apt4rpm (and, yes, I looked through the man page and FAQ) will apt4rpm automate this? If so, what do I need to do?
The dependency problem is INTENTIONAL!!!! (Score:2, Troll)
1. Distro created dependencies 75%
2. Dependencies created by nameing conflicts 15%
3. Real Dependencies 10%
Time and time again I've downloaded and edited the src rpm opened the spec file and found that SPECIFIC distro rpms are listed as dependancies rather than the dependencies created during the rpm -bb command. Thereby making sure that an RPM from distro A won't work on distro B. What really sucks is now that ATT has put me on a 56k cable modem I can't get the src RPM's or
Apt is only the half of dpkg's beauty (Score:3, Insightful)
o apt-get install galeon. Yes to install deps, blam! done.
o The true reason people love it so, and the reason it Works, is mainly due to the hard work, sweat and tears that the package maintainers put into each package. Each maintainer generally only handles either a single package, or just a few. With the 7-8k stable in all but name packages in Woody/testing, this represents a truely huge effort.
Not to belittle other distributions, but Apt has a huge advantage, solely due to the sheer amount of people hours that are put into tweaking every little package until it is just right. For a comercial distribution tho, this is cost prohibitive, and one maintainer must be responsible for many many base packages. The debian maintainers also QA addtional packages, so users arn't so much at the mercy of the setup that the origianal external software authors used.
I hope I don't come across as too much of a zealot, but it is really really really nice.
~.~
[OT] Make System (Score:3, Insightful)
./configure
make
make install
Is there anyway to uninstall it?
Re:[OT] Make System (Score:2)
You did remember to keep the source tree around, right
Re:[OT] Make System (Score:2)
If you really want to keep track of such things do a "find / > beforeInstall", then do "make install", then "find / > afterInstall". Put the two together, then sort and uniq, and you should have all the newly installed files. 'for $file in `cat installedFiles`; do rm "$file"; done' would wipe all the listed files.
Of course, then you have the potential problem of later removing a file that another package depends on (say, a cdr program needing cdrecord), but then you get into Dependencies and Package Management.
I remember mention of some utility that tracks installed files also, but I completely forget where I heard of it and what it's called.
Re:[OT] Make System (Score:3, Informative)
[gnu.org]
GNU stow
.
Re:[OT] Make System (Score:3, Informative)
./configure
make
make install
Is there anyway to uninstall it?
"make uninstall" will work in a lot of cases. With applications that use ./configure, it's usually pretty easy to turn it into a Debian package that you can install from by using the debmake, devscripts and sudo packages.
Go into the directory where ./configure is, and type "deb-make". Normally you want a "S"ingle Binary. This has now created a Debian build tree. Try to convert it into a package by running "debuild -rsudo". Hopefully this will spit out a .deb file in the parent directory. You can now install this by running "sudo debi". Dead easy.
To recap:
deb-make
s
debuild -rsudo
sudo debi
The package can be removed like any other package, e.g. via dselect.
Re:[OT] Make System (Score:3, Interesting)
make
make install
Uninstallation just involves removing the directory. This way I don't need to keep the source lying around and it's easy to change which version of the software I want to use. I usually do a
ln -s /usr/local/emacs-21.1 /usr/local/emacs
so I don't need to update my PATH every time I compile a new version.
The only downsides are that /usr/local gets pretty cluttered and PATH sure gets long, but it's worth it to me.
Hell? no just a small annoyance (Score:3, Interesting)
list of the ftp-accessible RPM
resources for your distribution. Use --test
with rpm -Uvh and when you have a
dependancy -- just grep your list(s) and
wget anything you need. In all, it keeps you on top of
what is going on with your system.
Not hell at all, IMHO.
I will share the scripts I use for mandrake if anyone wants them.
apt-get make-world (Score:2)
Ah, apt. (Score:3, Interesting)
#netselect-apt unstable; apt-get update ; apt-get -yd dist-upgrade ; apt-get dist-upgrade
Actually, probably replace those semicolons with && so commands proceed only if everything is ok.
It's a good time to be a Debian user :-)
One Directory (Score:2)
The LSB just creates more of this hassle, not less.
Stick everything in it's own directory instead of litering the world a la c:\windows
and I'd be a much MUCH happier person. As would many others I suspect.
i want to see two things... (Score:2, Offtopic)
/usr/local (Score:3, Informative)
I'd enjoy it if the base system stayed in
Re:/usr/local (Score:3, Informative)
/usr/local and
/usr is for the base system.
heard of ldd? (Score:2, Interesting)
This way, the package dependencies can be as trustworthy as
I've been a long time slackware user, and i'm so in love with autoconf/automake that i wish someone extended them to binary packages as well.
Sometimes, you're just not in a mood to compile the stuff up from source. I wish someone makes something out of this idea of mine.
Nikhil.
Re:heard of ldd? (Score:2)
It's just a difference in building rpms/debs and slackware.
When you package binaries, there are dependencies which are made by the packager's system.
If you compile it yourself it will only get linked to your libraries and headers.
With rpm you can set a BuildRequires, so the src.rpm can tell you what it needs to build. And you can set a Requires, which you can use to setup dependencies not found by ldd.
Shameless Debian plug (and thoughts on others) (Score:2)
And now for some quick anti-Debian FUD debunking:
1.) Debian is not harder to install and configure. If you have problems with it, you're either using an ancient version on modern hardware (ie. kernel fixes since then) or you are missing basic requisite knowledge that you should have with any distribution. Glossing it over now with a friendly GUI isn't going to help later when problems arise or you need to do something more complicated with your system.
2.) Debian is not slow and it does not suffer because default packaged binaries do not use Pentium optimizations. The performance increase with architecture optimizations is negligable for most software. And Debian does make full use of other compiler optimizations that do not break compatibility with certain hardware. On the other hand, if you would like heavier optimization, (say, PentiumPro or Athlon) for certain packages, Debian source packages work almost as smoothly as the BSD ports system.
Too much human interaction required (Score:2, Interesting)
The biggest problem with dependencies in RPM's is that there is a lot of human interaction required. I've seen A LOT of packages that require one of the following, thus causing a problem :
In each of these cases you have a problem. If I have Sendmail 10 installed and I'm installing an RPM that wants Sendmail 9, while I satisfy the requirements, it won't install. I'm not sure how debian deals with this.
If I have Exim installed, and I'm installing a package that wants Sendmail it won't install. Debian packages generally want MTA, a requirement which is satisfied by either Sendmail or Exim (or postfix for that matter).
If a package just wants a library without saying what package it comes from, apt is NEVER going to know what to install to satisfy that dependency without maintaining an Index of the contents of all packages.
These are deficiencies in the packages created by the package maintainers. There are other problems with the actual RPM way of doing things which are further compounded by the distribution builders.
A standard Mandrake install has about 30 packages as required that I have NEVER used. They are only required for certain circumstances, most of which I never needed. But I have to have that clutter lying around my system.
RPM is broken at 3 layers IMHO. The distribution builders, the package maintainers and the design of the application. Wrapping all of this in APT isn't going to solve anything. But until a viable alternative is marketted by someone with the power to drive it, RPM will remain the industry standard for commercially targetted GNU/Linux distributions.
Personally, I use FreeBSD and I love the make world solution for the base distribution and the ports solution for packages. This keeps me current, makes sure that all binaries are optimised to my processor and provides me with a one stop upgrade point. No hassles, no dependency woes and more time to get on with my job.
URPMI Hell (Score:2)
Recently, Mandrake added a kernel security update to their mandrakeupdate (urpmi) mirrors but placed a warning in the "details" section that states not to install the update through mandrakeupdate.
I'm not a total newbie but in an effort to bring my newly built system up to date quickly, I simply selected all security packages and installed them. Big mistake.
I know I should have known better but maybe there could have been at least one additional "dependency" to prevent users from using the wrong tool to install the RPM's for kernel updates and such.
A simple solution for RPM (Score:2, Interesting)
When you create an RPM, and upload it to a central depository, the checker would verify that the dependencies your package points to, exist there.
If you have perl21 alpha on your system, but perl 6 is the only version released as an RPM for a distro, then either make a perl21 RPM and upload that as well, or change the dependency to perl6, and see if your software still works.
If distros chose to keep 3 branches of development, they could be renamed.
stable
installable, and
advanced
If a proposed package did not have all of its dependencies in stable and installable, it could not go into either of these upload trees.
Completely automated package management could be made on a system that installs proposed packages, either on a pure system maintained by a maintainer, or in the chaotic user space, where through feedback of the installer, users could report back whether the package actually worked with the claimed dependencies. Automated user feedback systems could decide what goes into stable. Dependency trees could list all of the alternative versions of a single dependency which work, not because the author or maintainer have tested all versions, but automated user feedback has determined what works.
Trolls/hackers who intentionally falsify claims of operation could have an impact, but if there are 2 claims of the same configuration. One works the other doesn't, there is likely a way for it to work with that configuration.
Ximian Hosts KDE Packages; Why Deps Work (Score:3, Insightful)
Now, why do package management systems succeed or fail?
All package management systems have two issues: First, figuring out which packages are needed.
Second, going out and downloading them.
The first one is a matter of a file format with metadata and then parsing. It can be tricky but it's basically parsing. The second is a server management and control-of-system issue.
Debian's system, like Ximian's works reasonably well because it's more or less closed: very few packages will ever require something that isn't in one of the mirrors.
Download a random rpm, deb, or tgz from the net, and who knows what you'll get. Maybe it will ask you for something that's in a mirror. Maybe it won't. If you're lucky, it'll ask for something you can find somewhere.
Aaron Weber
Technical Writer
Ximian, Inc.
Mandrake's URPMI works quite well (Score:3, Informative)
I use both Mandrake and Red Hat. And IMHO, urpmi is better than up2date. I've been using urpmi (or its GUI interface, MandrakeUpdate) for a while.
And URPMI just plain works.
Every day, I fire it up to check if there's something to be updated on my system. If there is, I upgrade no problem. If there are dependencies, you can opt what to do. And it has the same interface as the SoftwareManager. So it's the same thing installing, uninstalling or upgrading.
This is called consistence.
I've read that some poster tried to update the Kernel with this tool from the GUI. I can only say "you moron!". When there's some Kernel to be upgraded, some library to be upgraded, I take my time to read what is this alla bout. So, reading a little can save your butt. What is wrong with that ?
Also, when updating KDE make sure that you are not running KDE. Idem with Gnome.
Anyway, I would recommend to home users wanting to avoid rpm-hell to try Mandrake + URPMI / MandrakeUpdate.
Hopefuly, Red Hat will take URPMI and implement it on their distribution.
All the best,
opkool
(sorry for the extension).
Re:a change (Score:3, Funny)
Personally, I dont hear too many new comments on /. anymore. I think that instead of writing everything out, we should recycle electrons and just use links to what someone else already said
That sounds a lot like an old Bill Gates legend, where he was tired of how circular arguments about technological religion would get. He joked that he needed a more terse way of talking to avoid the lengthy redundancies. "If I said 13, for example, that would mean 'that's the stupidest thing I ever heard,' and you could reply with 27 for 'maybe you should find somebody else to reinvent the wheel, then.'"
Re:a change (Score:2, Funny)
Two old lighthousekeepers lived in, well, a lighthouse far away from pretty much everything. All they did was sitting around all day telling each other jokes. Since they had lived together in the lighthouse for many, many years, they alread knew all the jokes and didn't laugh much at them. Who likes old jokes, right? But they didn't have anything else to do so they stuck to telling the old jokes anyway. One day they came up with the idea of enumerating all the jokes. That way they spent less time telling jokes and more time saying "haha". (They were already pretty tired of the old jokes, remember.) So the days went by something like this.
Keeper1: 16!
Keeper2: Haha.
Keeper2: 4!
Keeper1: Haha.
Well, you get the idea. But one day something exciting happened:
Keeper1: 12!
Keeper2: Haha.
Keeper2: 14!
Keeper1: Haha.
Keeper1: 256!
And keeper2 fell off his chair and rolled around laughing his ass off, because he had never heard that one before.
Ok, now I'll go hide in the corner of combined off-topic and lame joke shame.
Re:The problem is with the RPM format... (Score:2, Troll)
The question you're asking could be "why do people use RPM?" -or- "Why do people use RedHat, Mandrake, or SuSE?" I'll try to briefly give my answer to both questions.
Why do people use RPM?
As far as I can tell, RedHat and RPM came first. I never heard of Debian until RedHat got to version 3.0.x, and I never heard of anyone actually using Debian until even later. I think that I'm not the only one, either. Regardless, RPM was a hell of a lot simpler to use back then (I could create a binary RPM package in just two or three minutes, using my favorite text editor). Debian's system was a mess! Whoever wrote dselect had no clue. apt and dpkg didn't exist. I couldn't understand why anyone in their right mind would bother to create packages for Debian. So, I got better and better at RPM packages and kept ignoring Debian, because nobody ever used it and the software sucked. Eventually, someone finally wrote a real package manager for Debian, and I have to say that I was impressed. I decided to install Debian after that. And that leads us to...
Why don't people just give up their RedHat, Mandrake, etc and use Debian?
Because the people who use Debian are political wackos and elitist assholes! Yes, yes, I can see the (-1, flamebait) moderation hitting me hard right about now, but try to understand this is just my experience from being on the Debian lists and talking to Debian people on Usenet. I can't stand them. Someone on the main Debian mailing list once called me a 'hacker' in a derogatory sense! Funk dat. Debian people suck, and I haven't met a single one that I'd like to be associated with. They remind me of a combination of the worst qualities in OS/2, Amiga, Macintosh, and FreeBSD users. Maybe it's not like this today (the last time I used Debian was over 5 years ago), but that one experience so long ago soured me on Debian FOREVER. There is no chance of me using that distribution ever again. I refuse to be associated with people like that.
I'm sorry that this is flamebait, but I can't come up with a better, more tolerant way of putting it. Call it a personality clash, low tolerance for assholes, or me being immature... whatever you want... but I'll freely admit that Debian is an awesome Linux distribution.
I just want to use Linux. I don't want to join some stupid "Windoze SuX!!!!" club, I don't want to change my political party (I'm more of a green than anything else), I don't want to call my operating system GNU/Linux (wtf?) or Lignux or some crap like that, and I most definitely don't want to called names on the support mailing lists.
Maybe if someone archived the Debian mailing lists from 5-7 years ago, they'll see me getting flamed outrageously by Bruce Perens himself. It has always been my opinion that Perens, ESR, and most of the other people involved with Debian were blowhards, and this just reinforced my opinion.
Why do I use RedHat, Mandrake, SuSE, etc? Because they're quite good enough for the job (maybe not the best, but good enough), and the people who use them don't act like spoiled, egotistical 5 year olds.
Alright, let the moderation commence...
Re:The problem is with the RPM format... (Score:5, Interesting)
Why can't they let the merits speak for themselves? Bashing others just turns users away - users like me who don't care for the politics.
Re:The problem is with the RPM format... (Score:4, Insightful)
As a Red Hat user, you don't get to contribute unless you work for Red Hat. Since you got flamed hard on the Debian list, you must have posted there. If you posted there, then you must have wanted to contribute.
Now, is using Red Hat scratching that particular itch? No? Then why haven't you started your own distribution to scratch that itch?
On the other hand, perhaps you don't want to contribute to a distribution. Why then in that case would you care about the Debian list? I use Debian and don't post to the list because I'm not a Debian developer.
To sum things up bluntly: don't cut yourself off from a distribution that is top notch just because you think that the developers (many of whom are not the same people who treated you badly) are jerks. You can use the distribution without ever talking to them.
Re:The problem is with the RPM format... (Score:2)
Regardless, since you're obviously not interested in giving accurate statements about the current state of the Debian projects, its software, or its developers and users, why don't I throw out a URL for those that may be interested. You can simply over look this:
Re:The problem is with the RPM format... (Score:3, Insightful)
Whether something is a real server or not is not at all about the hardware it runs on, it's about what you use it for. And up to 2.4.16 you really don't want to run a 2.4 kernel on a server. Maybe you haven't had any problems with 2.4, but most people have. It would be much wiser to stick with one of the latest 2.2-kernels for a while until 2.4 has proven itself.
Re:The problem is with the RPM format... (Score:3, Insightful)
On the other hand, I'm still running 2.2 for our SQL server. After 2.4.16 and later have been tested by some other bleeding-edge people with database servers, I'll move it up. The VM problems and changes in the kernel seriously scared me away from making an early upgrade to 2.4.
It's all relevant to application.
Lest the parent rant affect everyone... (Score:2)
The debian-devel list(s) where the maintainers hang out are a lot tougher. They're not very nice to people who post inappropriately (i.e. if you don't know where to post, post to debian-user!) and they do have a low tolerance for hyper critical people, but they do welcome constructive criticism if it's polite, same as anywhere else.
I can't say I fully disagree with Elbereth's comments in terms of the developers, but I think that's a function of all the work they put in on a volunteer basis (thanks everyone!). I generally find that the difficulty of the package being maintained is proportional to how intolerant they are of clueless users, go figure.
The users are all very friendly and helpful in my experience though. The developers are also quite polite to people trying to be new package maintainers (the list for you is debian-mentor if you're thinking about this), so don't be too afraid to get involved. Just like anywhere else though, mind your manners and you'll be fine.
Community, not userbase. Consider.. (Score:5, Insightful)
Every single aspect of Debian's development, support, and growth comes from people who care about it enough to contribute their time. Does this tend to breed fanatics? Quite possibly. Is it understandable? Certainly to me. I don't see such fanatical support of other distros, because virtually all of them are developed by a company, not by a community.
Now, if that's not your cup of tea, great. There are plenty of other distros. That's the whole point, after all. That's the beauty of Linux's "fragmentation" that has forever been a point of criticism from the commercial software world which is so used to not having a choice.
Re:The problem is with the RPM format... (Score:2)
I know what you mean about some debian users. I mean I have seen some real assholes [slashdot.org] myself.
But another reason is ease of installation. I mean I know Red Hat and Suse are easy to install, easier then Windows 98SE. But Debian is hell to install, I mean even FreeBSD is easier to install then Debian.
I was able to install Debian because someone was willing to guide me over the install process. It took 3 nights and was done completely over IRC. So I can certainly tell you there are some really nice Debian users out there.
Re:The problem is with the RPM format... (Score:2, Informative)
Then you spout I just don't see why anyone would run Linux and not want to compile software, be on bleeding edge, and actually administer a UNIX system... I feel like I'm running Windows 95.
To which a "mean" guy answers Obviously, you never administered a high-availablilty multiuser machine... just your little hacker playtoy machine. Try explaining to 200-300 users that you'll be down for a few hours because you installed some new software, and broke the system.
If you expect anyone to be nice to you after saying: Unconfigurable software with horrid defaults, plain bad planning, changing industry standards without notice, etc. you need a reality check.
Then in 1997-06 someone has cc:ed the list a mail to you about a webpage where you give your "opinion" on Debian. Apparently it contained the same FUD you produced in January.
I didn't find any posts to you from Bruce Perens, but I hope he tore into you for being so rude and arrogant in your ignorance.
I see no reason for you to complain about any rudeness or flaming from Debian developers/users since you brought it to that level all by yourself.
Personally I moved (in 1996) from Slackware to Debian because Debian was more up to date. I was never inclined to whine to the Slackware developers about them not working harder to satisfy my "bleeding edge" needs though.
Re:The problem is with the RPM format... (Score:2)
Check out the reply calling me a hacker. It's classic.
Re:The problem is with the RPM format... (Score:2)
For reference, the message is [geocrawler.com]
http://www.geocrawler.com/mail/msg.php3?msg_id=
*
The problem isn't with the RPM format... (Score:2, Insightful)
You would perhaps like it to provide the author's favorite ice cream flavor, too?
Since different distributions and upstream authors all seem to have their own ideas on how to use dynamic library versioning,
Isn't this the problem entirely, and not the RPM format? If every library version number were updated the way it was supposed to be (backwards compatible in minor version number increments, API changes in major version number increments), then RPM works perfectly. I've seen it. Install version 2.3 of a library, and you can upgrade safely to 2.4 without breaking anything. If some bleeding edge packages needs version 3.0, then you install 3.0 *alongside* 2.4, and everything still works. Once the rest of your programs have been updated to use 3.0, you erase 2.4 and everything still works.
The big problem is what happens when this convention isn't followed, or when (worse yet) some library gets built into a FOO-bar.rpm by one guy and into a foo-bar-baz.rpm by another, so dependant software authors randomly choose one or the other, and you can't install both on your system. This could be solved if every author versioned correctly and every packager named correctly...
Or it could be solved the way Debian does it: with a single, authoritative package reposity. I occasionally have trouble getting a SuSE-built RPM to run on my Red Hat system. Debian users don't have this trouble, but if it's because of some superiority of
And don't get me started on ports. I play with alpha software and write C++, so I have a compiler and all sorts of header files installed... but you want to mandate that *everyone* have the same when they want to upgrade software? And enough RAM to compile it?
You could be right, of course.. there could be some vital missing feature of the
Re:The problem isn't with the RPM format... (Score:2)
If you had bothered to actually read my post, you would see that I do tell you: fine-grained dependency declaration. A DEB package references the other packages it requires, not the libraries or binaries contained in the package, thereby alleviating the problem of depending on different library versioning conventions. It also allows for pre- and post-dependencies, which help apt handle the often complex task of updating between major versions of Debian, by making sure that packages are updated in the proper order. This way, apt can successfully upgrade you from the old, libc5-based 1.3 distro to the latest unstable branch with practically no intervention. Try upgrading from Redhat 5.x to 7.2 sometime, and see how much work you have to put into it.
Re:The problem isn't with the RPM format... (Score:2)
This is exactly the wrong thing to do. How many different forks (what it takes to produce a "different library versioning convention" are there for the average Linux library? 1. How many different packagers (what it takes to produce different packages) are there? A half dozen, in RPM land.
Like I said, Debian doesn't avoid these problems because of technological superiority, they avoid it because they don't have different groups of competing packagers. That's great now, but it'll be ugly if they ever fork.
It also allows for pre- and post-dependencies, which help apt handle the often complex task of updating between major versions of Debian, by making sure that packages are updated in the proper order.
"Only update packages when all of their dependencies have been updated" is by definition a proper order. I don't think RPM currently does this (although I can't recall seeing a post-install script fail because of it; I probably don't update enough packages simultaneously except with full distro upgrades, which do maintain proper ordering), but that's a bug in the package tool, not a failing in the package format.
Interesting that you should mention forking. (Score:3, Insightful)
This happened a few times. Connectiva, Stormix, Corel, all essentially Debian forks. Y'know what happened? Corel sucked (And nobody was surprised), but Stormix and Connectiva remained compatible. In fact, it was common for Connectiva users to upgrade straight from an existing Debian install to a Connectiva release, or vis versa.
Just because more than one group is doing the packaging doesn't mean they'll be incapable of following the same rules. That's why Debian works with 300+ people making packages, after all, they follow the rules.
Re:The problem isn't with the RPM format... (Score:2)
What about dependency loops? How do you make sure that at no point does bash, or libc disappear or stop working? That's when fine grained dependencies come in handy.
Re:The problem isn't with the RPM format... (Score:2)
Not that there are a lot of people still running slink out there ( 4 years old by now ) or even 1.2 (hamm?) but it does mean this kind of thing is not entirely without minor gotcha's.
Furthermore, this is not the only potential problem. It has happened multiple times in the past that bugs in unstable / testing interfered with the stable upgrade path. Thinks like perl 5.6 come to mind. I'm sure most of those have been solved by now but don't expect an upgrade from stable to unstable to run smoothly all the time.
Re:The problem isn't with the RPM format... (Score:2)
RPM has this.
I believe RPM will handle this too, but I'd have to check the documentation.
This is almost entirely because RedHat didn't spend time on building their packages carefully to make this upgrade smooth. Whereas Debian developers are very careful about such things. Get hundreds of fanatical Debian developers building an RPM-based distro, and a commercially-focused Linux distributor using dpkg, and you'd see the same situation.
Re:The problem isn't with the RPM format... (Score:2)
I have never done that upgrade, however, I have done several 6.x to 7.x upgrades that went flawlessly. The last one I did was a 6.1 to 7.2. This was not a base install machine, it has many compiled packages and hacks as well. None of my config files were overwritten, I didn't run into any dependancy problems, it just worked as it was supposed to. I have 1 machine that runs Debian (actually, it's a root-nfs xterm) and I have had nothing but problems with the apt-get system on it. It failed installing packages a number of times. I would apt-get the package and tar (or gzip) would be unable to decompress it. Or the install script would fail. Or the dependancies wouldn't be met. It took many tries (and some good old fashioned tar.gz compiling) before I could get the system to the state in which I wanted it.
I realize these are just my experiences, but I have found RPMs to be much more reliable and easier to work with than debs. The one feature I wish RPMs had is automatically retrieving the packages to satisfy dependencies. RedHat's up2date is OK in this regard, but I have had some problems with earlier versions of it. I would like to see package retrieval built into RPM itself, not as a separate application. Other than that, I have been very satisfied with RPM.
Re:The problem isn't with the RPM format... (Score:2)
The difficulties with installing (say) SuSE packages on Mandrake are due to differences in the packaging conventions of those two distributions. And the ease of upgrading packages on Debian is because _all_ the packages come from a single source and follow a strict set of conventions. It has very little to do with the merits of dpkg versus rpm.
Re:The problem is with the RPM format... (Score:2)
Riiiiigghht. And that will happen straight after Debian adopts the graphical Mandrake installer, which is completely superior to Debian's tired old offering. It's all free software, after all, isn't it?
Re:The problem is with the RPM format... (Score:4, Informative)
Have you ever actually used RPM? It allows you to specify prerequisites with their versions in more or less the same way as dpkg. Certainly a lot more than just the version of shared libraries.
It's true that a lot of RPM builders do not bother to include this information. But that's not the fault of the format itself. A lot of the claimed advantages of .deb over .rpm are really just because the Debian people are more conscientous about packaging and anal (in a good way) about getting the dependencies correct. Ditching RPM is not the answer, better packaging quality is.
Re:The problem is with the RPM format... (Score:5, Interesting)
Debian/unstable is where new packages go. Here, packages are often built right from CVS. Yes, if you track Debian/unstable, you might get burnt every now and then from bugs. But on the whole, it's very good; everything is up to date, and it's about as stable and bug-free as a Red Hat
Debian/stable is almost totally static. The only reasons a package in Debian/stable is updated is for security reasons. Even then, usually, the fix will be backported to the version of the app that's in Debian/stable. For instance, if a long-present security bug is fixed in BIND 9.2.0, but Debian/stable asdlfkjasdglakjsdf, then the fix will be backported to that version; the package won't be upgraded right to 9.2.0. Why do this? "Stable" doesn't just mean apps that don't crash. It also means a common platform. Debian/stable will change only very, very rarely. This makes it an ideal target for sysadmins who wish to use trusted software, and for developers who want to target the lowest common denominator.
Yes, all three Debian trees use apt-get; in fact, moving from Debian/stable to Debian/testing is a matter of two or three commands, usually(ditto for Debian/stable -> Debian/unstable, or Debian/testing -> Debian/unstable). Almost all Debian mirrors have all packages from all trees in all supported architectures.
Re:The problem is with the RPM format... (Score:2)
Re:Nonsense. (Score:2)
So I should leave my exploitable wu-ftp server up and running, because I don't want a fix that is new? How about openssh? The fixed release of that is pretty new. Should I still be running my Bind 8 server? How do I tell when it is old enough that I can fix the bugs?
Heh (Score:2)
Re:APT for RPM-based systems (Score:2)
Correct me if I'm wrong on any of this, but:
- a 3-month testing phase before any code is released to the world as being "stable"
- dselect
- the best distro name
- speaking of which, a name that inspires trust from it's user base. It has the most stable "stable" out there.
- it's the first (and only?) linux distro NASA's used in outer space
- the only distro out there that's looking towards alternate free kernels, with an experimental GNU/Hurd distro available.
- the most flexible default linux configuration
dselect and replacements (Score:2)
After yesterday's article on making linux too hard, I went and grabbed the kpackage alternate for dselect. I've got to plug it, it was a bit slow and ate up the memory, but it shows a lot of promise as a great replacement for cufty dselect. I know there's a bunch of other potential heirs to the throne, but hopefully no one will ever have to use dselect again! It is a major barrier to entry on debian (even if it is powerful) and something a little more user friendly will do a world of good.
Kpackage isn't quite ready (it crashed on me a bit) but it's showing a ton of promise, and I'd bet the others are too. Once we toss dselect, it'll really be a major event for debian. Between that and the new installer I can't wait
Try Looking With Your Eyes Open (Score:2)
They may not be woody specific, but they work just as well for woody as they do for potato.
Re:Include the dependencies! (Score:2)
If you're installing from a distro's CD, then it should have all the dependencies right there, no problem.
If you're installing randomapp.tar.gz, then it's a bit more complicated. Sure, the tarball could include a copy of glibc, but why should it? My distro should include one that's up to date, and if it doesn't then perhaps you want to stick with the distro's method of adding libs so they can be easily removed later. For example, if I install a game that uses SDL, but that game isn't included on my distro CD, but the SDL libs it requires does, do I really want those libs to come from the download or from my distributer? I'll take the packaged SDL personally, just so it is easier to manage within the pre-exwhat you suggest is done on a lot of apps. For example, I just installed the Staroffice beta yesterday and all it required was a decent kernel and glibc. All the other libs were in there. You could throw all your requirements in to one huge package for download, it doesn't really jive with the modularity of the system, which makes for quicker downloads and less duplication of effort.
Re:Include the dependencies! (Score:2)
As a case in point, consider GnomeMeeting. I have an INTENSE professional interest in videoconferencing under Linux. GnomeMeeting shows considerable promise for fulfilling this need, but I can't get it to build under Debian woody. Despite the fact that I run apt-get upgrade at least once a week, the developer is apparently using some library more advanced than I have on my system
What's the point of all this? Developers
Re:Include the dependencies! (Score:2)
Granted, there are problems both ways, and I think the ability to have two packages, one with the libs and one with just dependencies that you have to fetch, would be a better solution.
But you're right, in the end the developer should be concious of what everyone else is running.
Re:Include the dependencies! (Score:2)
I'll say! If you can't love without any app, you've got some real issues to work through!
Its a flaw in open source.... (Score:2, Interesting)
You CAN'T do dependency checks accurately. Sure, with Windows you can check for the latest version of microsoft runtime libraries.......but, its easier........Microsoft is a closed-source system........they control the binary compilations......
For this reason alone, Microsoft and closed-source has a much EASIER time being used by the masses. Sure, you still get version conflicts, but I have not had one that I can remember in the last two years. Installers have now started checking version numbers, and they are getting smarter.
Linux will never get to this point while users are given the option of downloading binaries that may contain pre-compiled libraries from the application's developer........they could be a much older version, or some incompatibilities introduced.......but how would the system check??
The only solution I could see is a smart-dependancy checker that is able to get a list of specifications on the functions, and verify that each is there and working properly....and I don't see that happening.
Or... (Score:2)
Then, all apps that depend on those apps will have to depend on the versions that are in that central repository.
And you could create a strong policy that all items in that central repository must conform to and give it a cool name [debian.org] and you've beaten your seemingly inherent flaw.
Re:This Would Rule (Score:2)
Re:This Would Rule (Score:2, Insightful)
Yeah - trust me; this is the new kernel...
Re:Dependency Hell. (Score:2, Informative)
Simply edit your
I dunno how rpm does with it, but if you compile for yourself this is simple.