Slashdot Mirror


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.

15 of 386 comments (clear)

  1. rpm by ChazeFroy · · Score: 5, Funny

    rpm -Fvh slackware.rpm

  2. Unsolvable problems by err666 · · Score: 4, Insightful

    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.

    --
    reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
    1. Re:Unsolvable problems by Nailer · · Score: 4, Insightful

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

  3. run slackware by Eil · · 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.)

    1. Re:run slackware by ThatComputerGuy · · Score: 4, Informative

      While that is one of the more popular stances of Slackware users (and we're damn proud of it!), credit should be given where it's due, so it should be mentioned that slackware does actually have a Package Management System (hah! PMS! Get it?).

      Ever check the contents of files in /var/log/packages on a slackware system? Each file is for a different package, and simply lists all the files a package requires, total size, description, priority, etc.

      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 /var/logl/packages/kdelibs-2.2.1, and voila, all the files kdelibs installed/needs, the total filesize, etc

      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 /var/log/packages needs, it won't be removed.

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  4. My take on it. by dbarclay10 · · Score: 5, Insightful

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

    --

    Barclay family motto:
    Aut agere aut mori.
    (Either action or death.)
  5. Red Hat -> Debian via Connectiva apt by Nater · · 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.

    --

    I like to play children's songs in minor keys.
    "We're all sons of bitches now." --J. Robert Oppenheimer

  6. I've Said It Before: Debian is more than apt by krmt · · Score: 5, Insightful

    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.

    --

    "I may not have morals, but I have standards."

  7. that's missing the point by vscjoe · · Score: 5, Insightful
    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.

  8. What apt is about... by sydneyfong · · Score: 4, Informative

    the thing which makes apt really cool is not because it's using debs instead of rpm's.

    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.

    --
    Don't quote me on this.
  9. Re:The problem is with the RPM format... by dbarclay10 · · Score: 5, Interesting
    Hahaha :) Riiiight ;)
    The reason apt-get can keep things so incredibly up to date on a Debian system is because, ``incredibly up to date'' in Debian-speak means circa 1998 applications and libraries.
    You obviously don't use Debian. If you did, you'd be aware that "Debian" is really three distributions; Debian/stable, Debian/testing, and Debian/unstable. All of them are present on almost all mirrors, they're the exact same thing, except for the age of the packages.

    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 .2 release. After two weeks(generally speaking), the package in Debian/unstable is migrated to Debian/testing. If a package has existed in Debian/unstable without being updated by the maintainer for two weeks, then it's "safe enough" to go into Debian/testing. While there are some caveats with Debian/testing right now, it's what most desktop users use, and many server admins use it as well.

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

    Barclay family motto:
    Aut agere aut mori.
    (Either action or death.)
  10. Re:The problem is with the RPM format... by EvlG · · Score: 5, Interesting

    Add to your list of communities with offensive users LISP and some parts of Java. I can't stand to read Java books that denounce other programmers and other technolgies, and too many of the LISP books I have read do the same.

    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.

  11. Re:The problem is with the RPM format... by PD · · Score: 4, Insightful

    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.

  12. Community, not userbase. Consider.. by Cardinal · · Score: 5, Insightful

    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.

  13. Re:The problem is with the RPM format... by Ed+Avis · · Score: 4, Informative
    The RPM format at best only provides the name and major version of any dynamic libraries a package requires.

    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.

    --
    -- Ed Avis ed@membled.com