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

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

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.

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.

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.