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.

4 of 386 comments (clear)

  1. 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.
  2. 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.
  3. 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