APT - With Your Favorite Distribution

One of the most-heard complains from people who use distributions like Red Hat, Mandrake or SuSE is the "dependency hell" problem. You want to install an RPM and bang -- you have a dependency problem. There have been a few attempts to overcome dependency problems: SuSE with their YOU (Your Online Update), Mandrake with URPMI, and Redhat with their UP2date program. There is also a solution from Aduva called Aduvizor, but it's not supporting the latest distributions yet. Read on to learn about another interesting solution ... One of the solutions is Ximian Red Carpet (which is available to most of the distributions, freely or by subscription for increased download speed), however Red Carpet has one big problem -- if the package is not on Ximian Red-Carpet servers (like, umm, KDE packages), you're (again) on your own.

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.

Comments

Unsolvable problems

[err666]

Here comes an example from the real world: Apt/dpkg is no better than rpm. I can install cups without ghostscript and apt doesn't complain. I have this dependency with my printer, most probably others who use CUPS with a laser printer don't have the dependency.

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 .SPEC file said so.

Re:Unsolvable problems

[ninewands]

Don't blame hardware dependencies on the package tool, cups doesn't depend on ghostscript, so your ability to break your printing capability without upsetting apt is irrelevant.

On SuSE, I often used --nodeps for rpm, cos I *knew* that mutt doesn't *require* a spell checker, even if the stupid .SPEC file said so.

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 ... until I decided to go to a built-from-source 2.4.0 kernel back around the first of the year. In the process of updating my system utilities to the point that I could build 2.4.0, I broke something that destabilized the entire system ... might have been glibc-2.2.1, since it seems that the ld version I had upgraded to didn't like 2.1 ...

Anyhow, to make a long story short, I decided to install Debian woody. I ordered the CD set from the computerhelperguy 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 .tar.bz2 for their internal compressed archive. All I am saying with this overly-long and rambling post is that apt is the finest package management tool I have ever encountered, whether you are talking about Linux, Solaris, or any other n*x I've encountered.

Try it ... I suspect you'll fall in love with it, even though it only runs in text mode.

Re:Unsolvable problems

[PotatoHead]

The Software Manager 'swmgr' on SGI IRIX machines is pretty damn cool as well. Runs text 'inst' or GUI mode. Not only does it handle dependancies, but when there are conflicts, it provides you with choices you can work through. (They are in plain english and make a lot of sense.)

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

[Nailer]

This isn't a direct response to you, but to you and some of the other comments in the thread.
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 /etc/init.d -> /etc/rc.d/init.d symlink, all distro's will use /usr/share/doc, Caldera and SuSE won't put stuff in /opt, and maybe Debian will have to seriously consider using RPM (and perhaps fix whatever they think is wrong with it at the same time).

My take on it.

[dbarclay10]

First of all, this is oooold news. Connectiva has been around for a while, and they've used apt-get with RPM all that time. 'apt-get' was coded to be relatively package-manager-independant, so it's no surprise that another distribution has adopted its use.

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

I've Said It Before: Debian is more than apt

[krmt]

What you've said is the true power behind Debian. It's not really apt, as everyone likes to claim. It's in the social structure behind it. The policy and the extensive testing of each package makes the system work together so well to get rid of dependency problems. The fact that you've got maintainers looking after their individual packages and an open process with strict guidelines forces everything to behave.

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.

Afraid to use auto-updaters

[verbatim]

I'm very pessimestic about using auto-update tools. In fact, I dispise most install tools. I remember DOS being easy - one directory for pretty much everything to do with the OS: C:\DOS. Simple? Yes. Organized? No.

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.

that's missing the point

[vscjoe]

What makes Debian work is not apt/deb, but the fact that there is a big, distributed infrastructure of people doing the packaging and doing the testing. And that makes it work rather well, but it requires a lot of effort. And it still breaks occasionally, sometimes very seriously.

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.

Apt is only the half of dpkg's beauty

[nadaou]

The wonderfulness that is apt-get, and the dpkg engine that it runs, is two fold:

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

[Tachys]

I wanted to know if you install something using

./configure
make
make install

Is there anyway to uninstall it?

Re:The problem is with the RPM format...

[Anonymous Coward]

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.

I use Debian, and yet I have never muttered the aural monstrosity "GNU/Linux". I use Debian, and yet still voted for Dubya in the election. I use Debian, yet still recommend Windows 2000 to friends, relatives, and customers for whom the Microsoft platform is a better choice.

I could go on, but I think my point can be best summed up by the classic quote (not sure whom to attribute it to): 100% of generalisations are false.

The problem isn't with the RPM format...

[roystgnr]

The RPM format at best only provides the name and major version of any dynamic libraries a package requires.

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 .deb you never bothered to explain what that was. I rather suspect it's because Debian doesn't have the equivalent of SuSE: if you install a .deb package, you can be 99% sure that the guy who made it was using Debian.

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 .RPM file format... but it bugs me that nobody who marked you +5 seemed to notice that you never mentioned what this feature was!!!

Re:This Would Rule

[Zillatron]

I might be missing something here, but it seems to me that this is the thing that would be needed to finally make a big-splash linux worm viable.

Yeah - trust me; this is the new kernel...

Re:The problem is with the RPM format...

[PD]

I'm a Debian user, and I think that you're generalizing way too much. People love Debian because it's the best at the things that they care about, and they have the capability to contribute to it.

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.

Wow, talk about a grudge.

[Anonymous Coward]

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.

I pity you for your inability to look beyond a wild generalization from so long ago.

Community, not userbase. Consider..

[Cardinal]

The Debian community is so passionate because it is a distribution supported 100% by the people, and only the people. There's no commercial entity that funds the Debian Project. The release manager doesn't get a bonus if he gets the release out ahead of schedule, and the QA team doesn't get paid to manage packages that fall through the cracks.

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.

Interesting that you should mention forking.

[Cardinal]

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.

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.

To complete your analysis...

[Anonymous Coward]

For several years, Debian was plagued by packages with horribly broken dependencies. You'd install a package and this would cause a terrible, unrecoverable, inexorable, hours-long shitstorm of brokenness that sent many people to the store to buy a RedHat CD. I talked to this one guy at work who stopped using Debian in '96 and moved to BSD because of those problems.

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:The problem is with the RPM format...

[zmooc]

That's crazy. I run 2.4, and I've yet to have a single problem. What's that? I don't run real servers? How about a dual processor Pentium III and a DEC Alpha?

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

[Marasmus]

The utility of the 2.4 series kernel in production is completely dependent on what your server's functions are. For example, my employer has a specialised audio/video streaming daemon which suffered from (read: design problems) network subsystem performance problems in 2.2. These problems could be fixed with some kernel source modification and recompilation, but that degree of modification should not have been necessary (based on WHAT needed to be changed in the kernel). In 2.4, 90% of the things needing modification can now be set via /proc or sysctl. The other 10% were design limitations in the 2.2 series kernels which have been addressed and resolved (at least, to our application's satisfaction).

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.

Ximian Hosts KDE Packages; Why Deps Work

[chetohevia]

Ximian hosts all the packages that are included in your distribution. Including KDE. I've installed KDE with Red Carpet. No, really.

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.

what about BSD ports, BSD packages and APT?

[CoolVibe]

Not trying to sound like a *BSD bigot here, I _like_ apt... I wouldn't mind an apt-like system for BSD packages :-)

That said, isn't it completely possible to have APT play nice with BSD ports? i.e. I know apt can compile packages from source, this is where apt can fall back to ports, for instance. BSD also has packages (.tgz form) and a database for maintaining them (/var/db/pkg I believe). So I guess it's entirely possible to wrap APT around BSD's pkg_(add|delete|whatever). The BSD pkg_* tools are very powerful as well, since you can use regexps to remove/install a whole slew of packages, and other neat munchkin tricks. It's quite underrated, but that's kinda offtopic.

So why should you Linux whippersnappers have all the APT fun? :-)

FreeBSD has lots of utils to maintain ports (like portupgrade), but that just isn't quite as nice as apt.

The only problem I see is licensing (GPL vs BSD), but that's a whole different discussion I do absolutely do not want to get into (enough flamewars on FreeBSD-Current mailinglist already).

Apt only as good as packages being installed

[osjedi]

When using apt there are three primary factors affecting the success of the opperation.

1) Apt & it's ability to direct traffic.
2) The quality of the packages being installed, be they .deb, .rpm, or otherwise.
3) The quality of the "packages" files on the server you are retreiving packages from.

Apt will not work well if items 2 and 3 are poor. Garbage in == Garbage out. If high-quality packages are used, and the server they are on maintains accurate and up-to-date "packages" list files (where apt gets detailed info about the packages available for download) then apt will work very well. If you are still having dependancy problems with apt then it is likely that items 2 or 3 above are the root of the problem. If the food tastes bad you don't blame the plate.