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.

7 of 386 comments (clear)

  1. Um by rendler · · Score: 3, Interesting

    For apt to work to it's full potential you need a have a list of all available packages at the time in the current archive. Which debian has, so the question is how many of the other distros are doing this to make sure all the dependencies are currently in check? Cos I can see a lot of conficts to be had if there isn't one or isn't done properly.

    --

    *shrug*
  2. 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.)
  3. 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.

  4. Hell? no just a small annoyance by drDugan · · Score: 3, Interesting

    Use a script or scripts -- keep an up to date
    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.

  5. Ah, apt. by Macphisto · · Score: 3, Interesting
    apt just keeps getting better. Now it has front-ends that handle choosing the best mirror for you, so you can have guilt-free and speedy upgrading goodness.

    #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 :-)

  6. statistics by deno · · Score: 3, Interesting

    So we have: 5467 source packges (8558 binaries), and 934 registred maintainers. I.e. 6 sources, or 9 binary packs/maintainer, rather than 1-2. Still not bad, though.

    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.

  7. Re:[OT] Make System by mcfiddish · · Score: 3, Interesting
    To avoid having everything thrown into /usr/local, I've been doing this (with emacs, for example):

    ./configure --prefix=/usr/local/emacs-21.1
    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.