Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Linux Software

APT - With Your Favorite Distribution 386

Posted by HeUnique from the sounds-like-a-good-idea dept.
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.
This discussion has been archived. No new comments can be posted.

APT - With Your Favorite Distribution More

APT - With Your Favorite Distribution

Comments Filter:

  • rpm (Score:5, Funny)

    by ChazeFroy ( 51595 ) on Monday December 10, 2001 @12:47AM (#2680643) Homepage
    rpm -Fvh slackware.rpm

  • Unsolvable problems (Score:4, Insightful)

    by err666 ( 91660 ) on Monday December 10, 2001 @12:53AM (#2680653) Homepage
    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.

    • I've Said It Before: Debian is more than apt (Score:5, Insightful)

      by krmt ( 91422 ) <therefrmhere@@@yahoo...com> on Monday December 10, 2001 @01:12AM (#2680700) Homepage
      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.

      • To complete your analysis... (Score:2, Insightful)

        by 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.
    • 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 [chguy.net] 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.
      • 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 (Score:4, Insightful)

        by Nailer ( 69468 ) on Monday December 10, 2001 @05:31AM (#2681256)
        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).
        • > maybe Debian will have to seriously consider using RPM

          We're committed to using Alien for this. The LSB was designed with that in mine. If it had been a matter of the LSB requiring us to change to RPM, Debian would have probably left.

    • Re:Unsolvable problems (Score:2, Informative)

      by kigrwik ( 462930 )
      > I *knew* that mutt doesn't *require* a spell checker,

      This is why Debian has fiels called 'Recommends' and 'Suggests'. However, apt doesn't honor these, other frontends do (like aptitude)

      Package: mutt
      Depends: libc6, libsasl7, exim | mail-transport-agent
      Recommends: mime-support
      Suggests: locales, urlview, ispell, gnupg | pgp | pgp5i

      apt won't install ispell, but other aptitude will tell you that those packages are suggested or recommended by the package maintainer.

  • Um (Score:3, Interesting)

    by rendler ( 141135 ) on Monday December 10, 2001 @12:57AM (#2680667)
    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.
  • could this be what converts the hordes to linux? everyday you see it become friendly and more open to the newbies, now all you need is start button, a windows update icon and a blue screen of death.

  • Where's the aspirin? (Score:3, Funny)

    by cscx ( 541332 ) on Monday December 10, 2001 @12:59AM (#2680669) Homepage
    From slackware complaining that it's missing every .o file on the planet, to Red Hat bitching that I need a new version of RPM (and the new version of RPM telling me that I need another dependency... and so on) I've seen it all. But I hear there's this new Linux XP® coming out that'll solve all my problems! All I need to do is upgrade...

  • run slackware (Score:4, Informative)

    by Eil ( 82413 ) on Monday December 10, 2001 @01:08AM (#2680688) Homepage Journal

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

    • Re:run slackware (Score:4, Informative)

      by ThatComputerGuy ( 123712 ) <amrit@transamri t . net> on Monday December 10, 2001 @01:47AM (#2680790) Homepage
      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.
      • Another thing which seems to be rarely mentioned is that Slackware tries to be both Linux- and BSD- compatible, to as reasonable a degree as possible. In fact, it was one of Slackware's founding principles ("create the most unix-like linux possible"). Another strong rationale for us Slackware fans is that it's trivial at best to debate differences between most BSDs and Slackware. Hell, even Slackware's install script is a look-alike of FreeBSD's. :)

        Further down in this thread, someone mentioned the /usr/man versus /usr/share/man thing, etc etc... /usr/man is generally BSD-like, while /usr/share/man is Linux-like (linux filesystem standards dictate this). Also of important note is that in Slackware, /usr/share/man is a symlink to /usr/man. This leaves Slackware with a BSD feel while maintaining full Linux compatibility.

        Everyone makes a big deal about compiling from source in Slackware, or "not having a package management system", but completely ovelook the reasons why slackware doesn't appear to focus on package management.
        • Slackware is as unix-like as possible. POSIX (correct me if i'm wrong) does not dictate any package management standards of any sort.
        • Slackware's (very under-used) .tgz package manager is simple and works with VERY few problems. It's similar, though not straight-up compatible, with the BSD packages and ports... The package manager is very slackful itself, and allows you to compile lots of stuff yourself without unnecessarily bitching about dependencies. Sure, it can lead to non-uber-developers missing a dependent library when installing something big, but they can go back and add that library either by source or by package, and all is good.
        • Many RedHat-built packages (provided they're not built on GCC 2.96) work very well with Slackware, especially when converted to .tgz using rpm2tgz or any of its accompanying tools. These tools allow you to have the best of both worlds (fully packaged software and a super-lightweight, nearly transparent package manager).
        Slackware's developers follow the line of thought that package management is not and never will be an end-all solution to software installation on a *nix operating system. Instead of trying to force package management down the throats of their users, they prefer to take a split approach, giving some fairly good package management capabilities (also THE easiest to learn out of any linux package manager - it's SO simple) without discouraging source-compilation of software.

        forgive me if i've repeated myself a thousand times. i'm just ranting. :)

  • My take on it. (Score:5, Insightful)

    by dbarclay10 ( 70443 ) on Monday December 10, 2001 @01:10AM (#2680696)
    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).

  • Red Hat -> Debian via Connectiva apt (Score:5, Funny)

    by Nater ( 15229 ) on Monday December 10, 2001 @01:12AM (#2680699) Homepage

    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'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.
    • 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.
      I currently have 741 (rpm -qa|wc -l) packages installed on my work computer. And this is a pretty bare setup that I just use for work... no games or frivolities. That's a lot of packages to install by hand, upgrade, and keep track of...
      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"?
      The other day, I installed Evolution 1.0. I didn't need a webpage to tell me which dependencies I needed to satisfy; rpm complained for me. After downloading about 20 packages one at a time, by hand, I was able to install Evolution. The "download and install 20 supporting packages" bit is exactly what an automatic tool would have done for me. So why, exactly, was is preferable that I wasted ten minutes of my life downloading by hand? Evolution was a nice case, because all the required rpms were sitting in one place on the Ximian ftp server. When I upgraded all the requisite packages to compile linux 2.4 on a Red Hat 6.1 box a few weeks ago, though, the rpms were spread all over the world (rpmfind didn't have most of them), and it took literally *hours* for me to find and download all required rpms. Tell me again why this is preferable to an automatic tool?
      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?".
      In the halcyon days of DOS software installation that you pine over in your comment, what did you do if some program installed a library called lft321.dll? I presume your reaction was, "What the hell is that?" Or were you appeased because it was safely contained in a c:\games\pacman\libs directory, so you knew it was something pacman required? But then rpm gives you the same information: rpm -q --whatprovides FILE and rpm -q --whatrequires FILE. Instead of your libraries being spread out all over your file system, though, they're centralized. So, for instance, you don't need 20 copies of the same library sitting in various places on your disk, which should appeal to your "waste not" maxim.
      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.
      rpm doesn't allow you to do this. I'd like to hear an example that disproves this, because I've never encountered this problem in years of using rpm.
    • Oddly enough, I find this attitude all the time on linuxnewbie.org of all places. People are always advising newbies to install stuff from tar files instead of rpm. But with a modern system this is not a good thing.

      As another poster already pointed out, there are too many packages on a typical Linux system for one person to keep track of. On my computer I have just over 1000 packages installed.


      535~.$ grep "Status: install ok installed" /var/lib/dpkg/status | wc -l
      1012


      >> I guess I just have a thing for knowing exactly what is on my system.

      That's exactly why you should use package management. There is no way someone can keep track of over 1000 packages for even something like 7 years. If you are an employee you might not still be around in 7 years.

      >> why can't I just have a nice page saying something like: "you need these packages to [install|use|have sex with] this package?

      If you use debian, already do.


      541~.$ apt-cache show mozilla
      [snip]
      Replaces: mozilla-dmotif, mozilla-smotif
      Provides: www-browser
      Depends: libc6 (>= 2.1.2), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.7-1), libjpeg62, libpng2, libstdc++2.10, libz1, xlib6g (>= 3.3.6-4), libnspr4 (= M18-3), xcontrib
      Recommends: mime-support
      Suggests: postscript-viewer, pdf-viewer, eeyes | imagemagick | netpbm | xli | xloadimage | xv, xanim | ucbmpeg-play, freeamp | amp | splay | maplay | mpg123 | xmms
      Conflicts: mozilla-dmotif, mozilla-smotif
      [snip]


      >> 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?"

      Not too anal retentive at all. Here again package management is the solution to your problem.

      Pretend I don't know what package installs zipsplit.


      539/usr/bin.$ dpkg -S /usr/bin/zipsplit
      zip: /usr/bin/zipsplit


      Ah... zip installs zipsplit.

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

      Apt-get allways tells you what is going to be installed.


      ep13:/home/carp0110# apt-get install gnome-gnibbles
      Reading Package Lists... Done
      Building Dependency Tree... Done
      The following extra packages will be installed:
      gnome-games-locale
      The following NEW packages will be installed:
      gnome-games-locale gnome-gnibbles
      0 packages upgraded, 2 newly installed, 0 to remove and 70 not upgraded.
      2 packages not fully installed or removed.
      Need to get 612kB of archives. After unpacking 1768kB will be used.
      Do you want to continue? [Y/n]


      If you don't want to install the other packages just type 'n'.

      Also when debian changes a config file it always shows you the change and asks you if you want to do it. I sometimes am not sure and make a backup of the original just in case.

      The really good thing is that debian stores the old copies for you in /var/cache/apt/archives/ so you can downgrade back to the old version if something does break.

      Package management is nice for new users, but more importantly, it is good for people who don't want to reinstall their operating system every 5 years.

  • that's missing the point (Score:5, Insightful)

    by vscjoe ( 537452 ) on Monday December 10, 2001 @01:14AM (#2680702)
    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.

  • YOU (Score:2)

    by wishus ( 174405 )
    SuSE with their YOU (Your Online Update)

    YOU == YAST Online Update
  • I heard awhile back that Apple and the FreeBSD, NetBSD and OpenBSD teams were working together on a unified BSD packaging system derived from ports and apt that would allow packages to be installed across Darwin/Free/Net/OpenBSD. Anyone know what the status of this project is? Does it look like it will actually be adopted in favor of ports? Will there be a Linux version too?

  • What apt is about... (Score:4, Informative)

    by sydneyfong ( 410107 ) on Monday December 10, 2001 @01:26AM (#2680733) Homepage Journal
    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.
  • I just installed/ran apt4rpm, too, but only had 11 packages updated...but then I've been pretty good about running up2date --nox -u...

    Question: I want to update my KDE (from the default Redhat 7.2 distro) and I've never had success when I've tried downloading all the rpms manually and trying to solve the #&#*@ dependencies...as a new user of apt4rpm (and, yes, I looked through the man page and FAQ) will apt4rpm automate this? If so, what do I need to do?

  • Ever noticed that if you build the app from source you don't have all the dependencies you do from the rpm. Oh sure there are some build dependencies and of course You can't install a perl program and expect it to run on a box that doesn't have perl. The rest. Well they are intended for one purpose only. To sell you the latest version of the release. Why can't I install the latest KDE on my box when it's been built and released for one version up from me? Simple if I do. I might not by the disks for that version. If they built rpm's that were compatible with another distro then they run the risk of having you buy the other guys distro not theirs. Ever wonder why you can't install the Netscape rpm's without index.html?, but if you go to netscape.com and download the installer you don't need it? Or why if you put a redhat rpm on a mandrake box it looks for a redhat rpm and ignores the fact that you have that lib under a different rpm name? I build rpm's for a living and basiclly it comes down to this.

    1. Distro created dependencies 75%
    2. Dependencies created by nameing conflicts 15%
    3. Real Dependencies 10%

    Time and time again I've downloaded and edited the src rpm opened the spec file and found that SPECIFIC distro rpms are listed as dependancies rather than the dependencies created during the rpm -bb command. Thereby making sure that an RPM from distro A won't work on distro B. What really sucks is now that ATT has put me on a 56k cable modem I can't get the src RPM's or .gz files as easilly as before. So much for that. Ximian, up2date etc. are a great way to make money off of products that essentially are the same(the distro's). The only question I have is, why can I install Windwos + Office on a 2 gig drive and have lot's of room for data, but I can barely get Mandrake or Redhat to fit. Talk about bloat. Which is why my Libretto runs FreeBSD and X. Dependencies are creating a bloat situation of immense proportion.

  • Apt is only the half of dpkg's beauty (Score:3, Insightful)

    by nadaou ( 535365 ) on Monday December 10, 2001 @01:31AM (#2680745) Homepage
    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 (Score:3, Insightful)

    by Tachys ( 445363 ) on Monday December 10, 2001 @01:44AM (#2680784)
    I wanted to know if you install something using

    ./configure
    make
    make install

    Is there anyway to uninstall it?
    • make uninstall

      You did remember to keep the source tree around, right ;)
    • Occasionally there's "make uninstall".

      If you really want to keep track of such things do a "find / > beforeInstall", then do "make install", then "find / > afterInstall". Put the two together, then sort and uniq, and you should have all the newly installed files. 'for $file in `cat installedFiles`; do rm "$file"; done' would wipe all the listed files.

      Of course, then you have the potential problem of later removing a file that another package depends on (say, a cdr program needing cdrecord), but then you get into Dependencies and Package Management.

      I remember mention of some utility that tracks installed files also, but I completely forget where I heard of it and what it's called.

    • Re:[OT] Make System (Score:3, Informative)

      by juhtolv ( 2181 )
      One possibility is to use
      [gnu.org]
      GNU stow
      .

    • Re:[OT] Make System (Score:3, Informative)

      by SW6 ( 140530 )
      I wanted to know if you install something using

      ./configure
      make
      make install
      Is there anyway to uninstall it?

      "make uninstall" will work in a lot of cases. With applications that use ./configure, it's usually pretty easy to turn it into a Debian package that you can install from by using the debmake, devscripts and sudo packages.

      Go into the directory where ./configure is, and type "deb-make". Normally you want a "S"ingle Binary. This has now created a Debian build tree. Try to convert it into a package by running "debuild -rsudo". Hopefully this will spit out a .deb file in the parent directory. You can now install this by running "sudo debi". Dead easy.

      To recap:

      deb-make
      s
      debuild -rsudo
      sudo debi

      The package can be removed like any other package, e.g. via dselect.

    • Re:[OT] Make System (Score:3, Interesting)

      by mcfiddish ( 35360 )
      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.

  • Hell? no just a small annoyance (Score:3, Interesting)

    by drDugan ( 219551 ) on Monday December 10, 2001 @01:54AM (#2680809) Homepage
    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.

  • What debian really needs to truly kick as is a *BSD-like 'make world' feature. We've already got all the source-build dependencies - how hard could it be? As it stands, you currently need to set up some bizarre build-daemon system to compile sources for your own particular subarchitecture.

  • Ah, apt. (Score:3, Interesting)

    by Macphisto ( 62181 ) on Monday December 10, 2001 @02:16AM (#2680861) Journal
    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 :-)

  • I just wish packages would install in a single directory, with maybe a few very clear exeptions. I'm sick and tired of having to hunt down bits and peices of a packages all over about a thousand different paths.

    The LSB just creates more of this hassle, not less. /usr/bin is disgusting.

    Stick everything in it's own directory instead of litering the world a la c:\windows

    and I'd be a much MUCH happier person. As would many others I suspect.
  • I want to see two things in `configure` - a 'make uninstall` target being mandatory, and having part of `make install` copy the configure.status (or whatever script it is that holds the current configure string) to somewhere. The 'package' (source tarball) need not be aware of the existence of this script, really, just that it exists automatically as part of the install. That way, I can run it with some target like --uninstall and remove the binaries/man/etc stuff, or drop it into the source tree when I download from scratch (and have removed the original source tree).

  • /usr/local (Score:3, Informative)

    by sporty ( 27564 ) on Monday December 10, 2001 @02:44AM (#2680913) Homepage
    My major gripe about the way linux distribs work is that they like to install stuff right into /usr/bin and /usr/lib.

    I'd enjoy it if the base system stayed in /usr/bin, /usr/lib etc etc and whenver i wanted to, just rm -rf /usr/local (or /usr/X11R6 for X stuff) and be done with it. Plus removing the /var/db/pkg (or where-ever the package db files are stored)

    • Re:/usr/local (Score:3, Informative)

      by Arandir ( 19206 )
      You way of doing things is the RIGHT way of doing things. A few Linux distros do it the right way, but they are few, seldom seen, and never in the top three list.

      /usr/local and /opt are there for a reason. The only reason there's a /usr/X11R6 is because of stupid tradition, but there's no reason it couldn't be a symlink to /usr/local/X11R6.

      /usr is for the base system. /usr/local is for anything that you install after the initial install, even for stuff that ships with the OS. /opt is optional, but useful for network installations so that what the user installs is under /usr/local and what IT/administration installs is under /opt.

  • heard of ldd? (Score:2, Interesting)

    by nikhilwiz ( 176218 )
    My approach to making a package format is running 'ldd' on every executable and then recording the dependencies, within the package. Any extra binary packages required (for eg. progs exec'ed from the application) can be entered by the user at the time of building the package.

    This way, the package dependencies can be as trustworthy as ./configure'ing it from source. I'd prefer an equivalent mechanism adapted into making a package and figuring out its dependencies.

    I've been a long time slackware user, and i'm so in love with autoconf/automake that i wish someone extended them to binary packages as well.
    Sometimes, you're just not in a mood to compile the stuff up from source. I wish someone makes something out of this idea of mine.

    Nikhil.
    • Yup, And it's also done by rpm afaik.

      It's just a difference in building rpms/debs and slackware.
      When you package binaries, there are dependencies which are made by the packager's system.
      If you compile it yourself it will only get linked to your libraries and headers.

      With rpm you can set a BuildRequires, so the src.rpm can tell you what it needs to build. And you can set a Requires, which you can use to setup dependencies not found by ldd.
  • Debian (and deb/apt packaging) is successful because it is a community project. Thousands of people working in harmony towards a common goal, each doing their own small part with great care will always outperform a commercial effort. That's the core strength of the Open Source movement, minor politics aside. Does such collaboration always happen that way? Of course not. But when it does, it's a wonderful thing. And with the Debian project, it has. RedHat, Mandrake, et.al. have largely ignored this concept and this makes me rather leary. Corporations exist primarily to produce "value-added" products and services. Nothing's wrong with that. But you don't truly add value to Open Source software by packaging it in non-standard or inferior ways, especially when complete and superior distributions already exist. So why make your own distro that has all sorts of quirks and discrepancies? To trap less adept customers into needing your tailored support services for that specific distribution. And to familiarlize less adept administrators with supporting your own distribution's quirks so they don't feel like switching. Don't get me wrong, there's a huge market for Open Source support services. But breaking away from the community spirit and doing things your own way is not the way to do it. There is absolutely no valid reason for there to be so many distributions of Linux and related OSS. And there is no reason why Linux companies cannot just support community-based distributions like Debian and Slackware. Or maybe they're afraid they'll actually have to face competition in providing the best support services.

    And now for some quick anti-Debian FUD debunking:

    1.) Debian is not harder to install and configure. If you have problems with it, you're either using an ancient version on modern hardware (ie. kernel fixes since then) or you are missing basic requisite knowledge that you should have with any distribution. Glossing it over now with a friendly GUI isn't going to help later when problems arise or you need to do something more complicated with your system.

    2.) Debian is not slow and it does not suffer because default packaged binaries do not use Pentium optimizations. The performance increase with architecture optimizations is negligable for most software. And Debian does make full use of other compiler optimizations that do not break compatibility with certain hardware. On the other hand, if you would like heavier optimization, (say, PentiumPro or Athlon) for certain packages, Debian source packages work almost as smoothly as the BSD ports system.

  • The biggest problem with dependencies in RPM's is that there is a lot of human interaction required. I've seen A LOT of packages that require one of the following, thus causing a problem :

    • Specific sofware package (eg. Sendmail)
    • Specific version of package (eg. Sendmail 9.1.0)
    • Just a library without saying what package to get it from (eg. libperl.so)

    In each of these cases you have a problem. If I have Sendmail 10 installed and I'm installing an RPM that wants Sendmail 9, while I satisfy the requirements, it won't install. I'm not sure how debian deals with this.

    If I have Exim installed, and I'm installing a package that wants Sendmail it won't install. Debian packages generally want MTA, a requirement which is satisfied by either Sendmail or Exim (or postfix for that matter).

    If a package just wants a library without saying what package it comes from, apt is NEVER going to know what to install to satisfy that dependency without maintaining an Index of the contents of all packages.

    These are deficiencies in the packages created by the package maintainers. There are other problems with the actual RPM way of doing things which are further compounded by the distribution builders.

    A standard Mandrake install has about 30 packages as required that I have NEVER used. They are only required for certain circumstances, most of which I never needed. But I have to have that clutter lying around my system.

    RPM is broken at 3 layers IMHO. The distribution builders, the package maintainers and the design of the application. Wrapping all of this in APT isn't going to solve anything. But until a viable alternative is marketted by someone with the power to drive it, RPM will remain the industry standard for commercially targetted GNU/Linux distributions.

    Personally, I use FreeBSD and I love the make world solution for the base distribution and the ports solution for packages. This keeps me current, makes sure that all binaries are optimised to my processor and provides me with a one stop upgrade point. No hassles, no dependency woes and more time to get on with my job.

  • My recent problem was not too many dependencies but too few.

    Recently, Mandrake added a kernel security update to their mandrakeupdate (urpmi) mirrors but placed a warning in the "details" section that states not to install the update through mandrakeupdate.

    I'm not a total newbie but in an effort to bring my newly built system up to date quickly, I simply selected all security packages and installed them. Big mistake.

    I know I should have known better but maybe there could have been at least one additional "dependency" to prevent users from using the wrong tool to install the RPM's for kernel updates and such.
  • would be an RPM upload checker...

    When you create an RPM, and upload it to a central depository, the checker would verify that the dependencies your package points to, exist there.

    If you have perl21 alpha on your system, but perl 6 is the only version released as an RPM for a distro, then either make a perl21 RPM and upload that as well, or change the dependency to perl6, and see if your software still works.

    If distros chose to keep 3 branches of development, they could be renamed.

    stable
    installable, and
    advanced

    If a proposed package did not have all of its dependencies in stable and installable, it could not go into either of these upload trees.

    Completely automated package management could be made on a system that installs proposed packages, either on a pure system maintained by a maintainer, or in the chaotic user space, where through feedback of the installer, users could report back whether the package actually worked with the claimed dependencies. Automated user feedback systems could decide what goes into stable. Dependency trees could list all of the alternative versions of a single dependency which work, not because the author or maintainer have tested all versions, but automated user feedback has determined what works.

    Trolls/hackers who intentionally falsify claims of operation could have an impact, but if there are 2 claims of the same configuration. One works the other doesn't, there is likely a way for it to work with that configuration.

  • Ximian Hosts KDE Packages; Why Deps Work (Score:3, Insightful)

    by chetohevia ( 109956 ) on Monday December 10, 2001 @10:43AM (#2682144)
    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.

  • Mandrake's URPMI works quite well (Score:3, Informative)

    by opkool ( 231966 ) on Monday December 10, 2001 @12:19PM (#2682657) Homepage
    Hi,

    I use both Mandrake and Red Hat. And IMHO, urpmi is better than up2date. I've been using urpmi (or its GUI interface, MandrakeUpdate) for a while.

    And URPMI just plain works.

    Every day, I fire it up to check if there's something to be updated on my system. If there is, I upgrade no problem. If there are dependencies, you can opt what to do. And it has the same interface as the SoftwareManager. So it's the same thing installing, uninstalling or upgrading.

    This is called consistence.

    I've read that some poster tried to update the Kernel with this tool from the GUI. I can only say "you moron!". When there's some Kernel to be upgraded, some library to be upgraded, I take my time to read what is this alla bout. So, reading a little can save your butt. What is wrong with that ?

    Also, when updating KDE make sure that you are not running KDE. Idem with Gnome.

    Anyway, I would recommend to home users wanting to avoid rpm-hell to try Mandrake + URPMI / MandrakeUpdate.

    Hopefuly, Red Hat will take URPMI and implement it on their distribution.

    All the best,
    opkool
    (sorry for the extension).

Slashdot Top Deals

Only great masters of style can succeed in being obtuse. -- Oscar Wilde Most UNIX programmers are great masters of style. -- The Unnamed Usenetter

Close