The Great Package Management Experiment [LWN.net]

September 24, 2003

This article was contributed by Ladislav Bodnar

Last week's Revisiting RPM Package Management in the distribution section of LWN was quickly followed by a heated debate about software management in various distributions. Predictably, the discussion soon evolved into a full-scale "distro war", where each distribution was vigorously defended by its respective vocal fans. This heated feedback resulted in an attempt to conduct a practical experiment. It will examine the package management tools in five major binary Linux distributions (Debian, Mandrake, Red Hat, Slackware, SuSE) and provide examples of 1) installing a package not officially supplied by the distribution itself and 2) upgrading the entire distribution to a newer version. Without any further ado, let's get on with the show, in alphabetical order.

Debian GNU/Linux

I chose MPlayer for the test of installing a third-party package. MPlayer is a popular media player for Linux, but most distributions do not supply it due to potential legal issues with certain codecs included in the package. Debian is no exception. Luckily, visiting apt-get.org and typing "mplayer" into the site's search engine reveals the availability of MPlayer from a number of unofficial repositories, as well as instructions for adding the repository to one's sources.list. In case of Debian Woody, this is a simple matter of adding 'deb http://marillat.free.fr stable main' to /etc/apt/sources.list, then executing the following:

    apt-get update
    apt-get install mplayer

That's all to it, MPlayer is now installed and ready for use.

As far as upgrading the Debian distribution to the latest version, this is done with a single command:

    apt-get dist-upgrade

This is a well-tested, well-documented and reliable procedure for upgrading a Debian system. The ease of package installation (whether native or third-party) and system upgrades are often considered to be some of the most pleasant aspects of using Debian GNU/Linux and this is hard to argue. Overall score (on a scale from 1 to 10): third-party package installation: 10, distribution upgrade: 10.

Mandrake Linux

Like Debian, Mandrake does not supply MPlayer as part of the distribution. A quick trip to Penguin Liberation Front (PLF) reveals availability of the package, together with instructions on how to add the necessary sources to Mandrake's package manager - urpmi. The site also provides a well-designed three-step wizard, which enables users to specify a Mandrake version, select official Mandrake mirrors and choose to add other third-party repositories, such as PLF itself, Texstar's RPMs and Java RPMs. The wizard outputs a number of urpmi.addmedia commands that need to be executed from the command line - a simple copying and pasting those into the Konsole does the trick. As soon as the execution completes, MPlayer can be installed with:

    urpmi mplayer
    uprmi mplayer-gui

The first command gives an option to choose between a stable or development version of MPlayer, which is followed by a prompt to confirm installation of dependent files. Mandrake's package manager then goes on to fetch and install all the necessary files. In the test, everything installed flawlessly and typing "gmplayer" on the command line launched MPlayer in its full glory.

That was nice, but let's try something more challenging - such as updating the entire distribution. At the time of the experiment, Mandrake Linux 9.2 was not yet released, but the distribution's development branch called "Cooker" was very close to what the final Mandrake 9.2 would look like, sans some last minute bug fixes. I followed the instructions in Cooker HOWTO and How to Upgrade Mandrake, updated the urpmi sources to point to a fast local mirror and executed the following commands:

    urpmi.update -a
    urpmi --auto-select --no-verify-rpm --auto
    urpmi kernel

The entire upgrade procedure was a surprisingly pleasant experience. All completed without a single hitch and when I rebooted the system, I found myself in a brand new Mandrake Linux 9.2, almost final. Comparing the upgrade process to Debian, the only downside is that three commands are needed to upgrade Mandrake, as opposed to a single command for upgrading Debian. The overall score: third-party package installation: 10, distribution upgrade: 9.

Red Hat Linux

Red Hat Linux 9's only package updating tool with dependency resolution is up2date. This was primarily designed for updating an existing installation with critical bug fixes and security patches, rather than as a general purpose package management tool. It is not possible to add third-party repositories to up2date and non-subscribers require to fill in a lengthy registration form every few months. But even paying subscribers have reported frequent failures to connect to up2date servers shortly after Red Hat's security advisories.

Currently, there are two third-party tools with dependency resolution capabilities for Red Hat Linux - apt-get and yum. For the MPlayer installation experiment, I settled on apt, which is trivial to set up on any recent Red Hat installation - a quick trip to freshrpms.net was all that was required to download the relevant RPM package and install it manually. Afterward, installing MPlayer and all of its dependencies was also a no-brainer:

    apt-get install mplayer

As soon as the installation process completed, MPlayer was ready for use.

Next came the task of upgrading a vanilla Red Hat 9 to Rawhide, which is Red Hat's development branch, probably fairly close to a new beta expected to be released shortly. Here I chose yum for the job, mainly because yum is now included in the Rawhide and presumably it will be included in the next official Red Hat Linux release. The package is also available from freshrpms.net. After configuring the sources, I issued the following commands:

    yum check-update
    yum -t -y upgrade

Perhaps being spoiled by a very easy Mandrake upgrade, I expected a similarly smooth flow while upgrading Red Hat. Unfortunately, it wasn't the case. The upgrade proved to be a lot of hard work and here is the summary of my observations:

One of the main disadvantages of the yum package manager is that it only works with a Red Hat mirror, which has been "yumified". A yumified mirror contains a separate directory with header files of every available RPM package. At present, not many mirrors appear to have been yumified.
The upgrade process aborted with errors on countless occasions. Even a simple error such as a failure to download a package for whatever reason brought the upgrade to a halt and had to be manually restarted. Once restarted, yum went through a lengthy dependency checking period, despite the fact that no change had been made to the package selection. Also, yum does not seem to have the ability to re-try fetching a package in case the first attempt fails.
A major upgrade such as this one can take many hours, but unlike Debian or Mandrake's package managers, yum gives no indication about the progress or estimated time left.

Nevertheless, the upgrade eventually completed and I was able to boot into a newly upgraded development version of Red Hat Linux. Perhaps another detailed comparison of yum with apt would be useful here, but I'll leave it for another time when we know more about Red Hat's (or Fedora's) direction in terms of its package management. Worth mentioning here is an interesting comment by one of the readers in last week's forums, which deserves to be quoted here:

Although yum is now in rawhide, I don't expect to see it in a released version of RHL or RHEL. Why do I say this? Because the newest up2date that will ship with the upcoming RHEL and RHL now supports remote "yum" and "apt" repositories in addition to the native "rhn-style" repositories. Since up2date now speaks all languages (rhn, apt, yum) there is no need to ship those other tools.

Overall score (2 points were deducted for having to use a third-party package manager): third-party package installation: 8, distribution upgrade: 3.

Slackware Linux

Slackware's package manager does not have the ability to resolve dependencies. The MPlayer experiment started with a trip to LinuxPackages, where I located and downloaded the necessary package, then executed installpkg:

    installpkg mplayer-1.0pre1-i686-2rob.tgz

Although no errors were reported during installation, MPlayer failed to launch due to missing libraries. Back to LinuxPackages to download alsa-lib, lame and libdvdread (the dependent packages were clearly listed on the MPlayer download page), before installing them with installpkg. This has satisfied all requirements and MPlayer was ready for action.

There are three third-party packages that handle Slackware package updates - these are swaret, slackpkg and slapt-get. Both swaret and slackpkg have now been officially included in the "extra" directory of Slackware Linux, but between the two of them only swaret has the ability to resolve dependencies, while slackpkg is generally used to keep a Slackware system synchronized with the "current" branch (i.e. development branch, equivalent to Sid, Cooker or Rawhide). At this point, it is perhaps interesting to note a recent comment by Slackware's creator Patrick Volkerding, which indicates that not everybody thinks highly about advanced package management tools: "I'm not a big believer in automated dependency handling."

As with all other distributions in this experiment, I wanted to upgrade a vanilla Slackware 9.0 installation to the latest available development version, which at the time of writing was Slackware Linux 9.1-beta2. This can be done with Slackware's native tools, but the process is fairly involved, it requires manual download of all upgraded packages, which then need to be upgraded with upgradepkg in a certain correct order. After downloading and installing swaret, the same could be achieved with two commands:

    swaret --update
    swaret --upgrade -a

Again, the process took time, but completed with no errors. Several newly upgraded packages required extra packages to satisfy dependencies and this is the only place where user intervention was called for to confirm the action. But the overall experience was very similar to upgrading Mandrake, except that it required a third-party tool.

Overall score (2 points were deducted for having to use a third-party package manager): third-party package installation: 5, distribution upgrade: 7.

SuSE Linux

As many readers correctly pointed out, SuSE's native package manager called YOU (YaST Online Update), does indeed have dependency resolution capabilities. My apologies to SuSE users for the erroneous claim to the contrary. The reason which led me to believe otherwise was the frequency with which questions about apt-get come up on SuSE's mailing lists. Upon some investigation, it would appear that the main reason for apt-get's proliferation and preference among SuSE users is that certain third-party repositories of SuSE packages encourage users to make use of it. The popular usr local bin, which provides up-to-date GNOME packages is a good example. Another major advantage of APT for SuSE is its ability to upgrade the entire distribution with a single command and without re-installing. According to this comparison chart YOU cannot be used for this purpose.

Keeping uniformity in the package installation experiment proved difficult, because SuSE is the only distribution in this list that does ship with MPlayer. However, some of the useful, but legally questionable components and plugins are missing from it, so let's try to install a more useful version, such as the one found at links2linux.de. Unfortunately, attempting to add the source of the MPlayer package to Software Source Media in YaST resulted in a "ERROR(InstSrc:E_no_instsrc_on_media)" message. But after installing apt and its dependencies, and updating apt's sources, MPlayer installed with a single command:

    apt-get install MPlayer

The test of upgrading the entire SuSE 8.2 distribution to a newer version could not be done, simply because a newer version of SuSE Linux has yet to be released. It will probably be another two months before SuSE 9.0 directories appear on mirrors to give apt-get a chance to do its magic. Overall score: third-party package installation: 6, distribution upgrade: not rated.

Conclusion

To conclude this lengthy and time consuming experiment involving package installations and distribution upgrades, we have two clear winners - Debian and Mandrake. Debian is hard to beat when it comes to overall convenience, but Mandrake has made a lot of effort and its urpmi package management and underlying technology has just about succeeded in catching up with Debian's. The other three distributions have a long way to go. Red Hat is currently in a major transition and the question of package and distribution upgrades is probably being addressed as I write this. Slackware is easy to upgrade with swaret, a tool which will be included in the upcoming Slackware 9.1, but it doesn't handle installing packages from third-party repositories. As for SuSE, it falls short of all other distributions. YOU has a pleasant interface and it works extremely well within its official package set, but as a software management tool, it has too many shortcomings to compare well with either apt-get or urpmi.

(Log in to post comments)

Organizational Effects?

Posted Sep 25, 2003 3:33 UTC (Thu) by brugolsky (subscriber, #28) [Link]

This is a very good point. The value in Debian is not so much in dependency resolution, it is in good packaging discipline, testing, bug-tracking, and one-stop-shopping centralization. The RPM world is plagued by incompatibilities (some minor, some not) between Red Hat, Mandrake, PLD, ALTLinux, etc., as well as lack of a unified repository and bug-tracking. (And I'm mostly a Red Hat partisan!) SourceForge was intended to solve this, but it hasn't turned out that way.

The original Fedora Project began the task of building a Red Hat-compatible package repository with the same desirable features of Debian listed above. As the Fedora project builds out its tools and infrastructure, it seems likely that it will begin to accumulate many more high-quality packages that work together seamlessly.

But the example of installing mplayer illustrates one of many challenges faced by Fedora, such as how to manage meta-data (searching, dependency tracking, signatures, bug-tracking, even multi-platform compilation) for packages that Red Hat cannot legally distribute, nor facilitate distribution.

I am confident that the need to solve the legal problem will spur the development of a more robust and scalable infrastructure that is both distributed and not strictly hierarchical.

Organizational Effects?

Posted Sep 26, 2003 18:40 UTC (Fri) by ranger (guest, #6415) [Link]

The value in Debian is not so much in dependency resolution, it is in good packaging discipline, testing, bug-tracking, and one-stop-shopping centralization.

The problem though is that Debian users think they have a monopoly on this.

Maybe the Debian aren't aware of this, but a number of other-distros have many of the same contraints on packagers, and many similar tools/methods.

The RPM world is plagued by incompatibilities (some minor, some not) between Red Hat, Mandrake, PLD, ALTLinux, etc., as well as lack of a unified repository and bug-tracking.

The only difference here is that the only distributeable .deb's are from Debian. If .deb were more wide-spread, you would have the same problem. The problems with incompatible RPMs are mostly attributeable to the success of rpm. However, many of the same principles apply. If there are official packages for your release of your distro, use them. Otherwise, try some others but beware.

The original Fedora Project began the task of building a Red Hat-compatible package repository with the same desirable features of Debian listed above.

And this is something that Mandrake has been addressing for a number of years, which is why there are well-maintained community-supplied packages in the main distribution and in contrib.

And for Mandrake, this is where the PLF comes in. This is the only departure from the "one-stop" shopping you mentioned above, but PLF follows a lot of the same principles in Mandrake, and is maintained to always be compatible and trivial to use.

Organizational Effects?

Posted Sep 27, 2003 13:57 UTC (Sat) by maney (subscriber, #12630) [Link]

The only difference here is that the only distributeable .deb's are from Debian. If .deb were more wide-spread, you would have the same problem.

This proves not to be the case; at least, there are many unnofficial sources for packages wrapped up in .deb form, and in my admittedly not extensive experience they work just fine. Of course you'll want to keep an eye on what other changes may be needed by some packages, but that's going to be true no matter what format the package is in. You can get some idea of the scope of third-party .deb packages by visiting apt-get.org.

Or did you mean to suggest that there are no complete .deb-based distros other than the official Debian? That's not true either, though there certainly are more that are RPM-based. Knocking off a new distro by taking the then-current Red Hat and making a few changes was something of a cottage industry in the late nineties. There's less need for such splintering with Debian, since anyone who really wants an obscure package added to Debian can generally achieve that goal unless there's some legalistic restriction (as with the example of mplayer in this comparison). The Fedora Project ought to help with that - indeed, it seems to aim to recreate a distinctly Debian-like organization aside from (I think) continuing to use RPM packages and something other than apt for package management. <wink>

Organizational Effects?

Posted Sep 29, 2003 23:20 UTC (Mon) by ranger (guest, #6415) [Link]

This proves not to be the case; at least, there are many unnofficial sources for packages wrapped up in .deb form, and in my admittedly not extensive experience they work just fine.

But, they are all for Debian.

If you use RPMS made explicitly for Mandrake on Mandrake (which are also available in many places), they also work fine. The problems of binary packages come in when you install them on a different distribution, with different library versions etc (which break dependencies, and since the release cycles are more than once a decade the ancient package may not be provided in a suitable repository ;-)).

You can get some idea of the scope of third-party .deb packages by visiting apt-get.org.

It seems like >50% of these sites are just back-ports from unstable/testing, which is only necessary on Debian due to the excessively long release cycle. Most rpm-based distros have packages of the same version in their stable releases, so there is no need for backports. For instance, samba packages aren't necessary, since all supported Mandrake releases have 2.2.7a from updates, but there are 2.2.8a pacakges avaialble from the urpmi medium on the samba FTP mirrors, and these have an additional set of LDAP-enabled packages.

Anyway, you can visit http://plf.zarb.org/~nanardon/?minor=1, and see that there are a number of third-party urpmi media for the few cases where backports are necessary or where software is not welcome in the distro or contrib (due to licensing problems).

BTW, in the sentence " The only difference here is that the only distributeable .deb's are from Debian.", "from" should be taken to mean "built on". I don't think the Lindows users are out there in their masses builing Deb's ...

Or did you mean to suggest that there are no complete .deb-based distros other than the official Debian?

Of course not, but they aren't quite "distributeable" in the way I meant it (unless there are public mirrors for the current version of Libranet etc).

There's less need for such splintering with Debian, since anyone who really wants an obscure package added to Debian can generally achieve that goal unless there's some legalistic restriction (as with the example of mplayer in this comparison).

And there's even less need for this in Mandrake (I am not a Mandrake employee, but maintain packages in main, and many more in contrib). For instance, 9.2 will be release with a full set of free Java software in the form of the Jpackage RPMS, which is a comprehensive set of packages (so much so that you can 'urpmi eclipse' and get *all* the dependencies).

The Fedora Project ought to help with that - indeed, it seems to aim to recreate a distinctly Debian-like organization aside from (I think) continuing to use RPM packages and something other than apt for package management.

And this is what Mandrake has been doing for a long time, but nobody seems to notice that, or even take their time to check the facts ...

The Great Package Management Experiment

Posted Sep 25, 2003 10:01 UTC (Thu) by Algol (guest, #2681) [Link]

and does apt-upgrade upgrade the kernel?

The Great Package Management Experiment

Posted Sep 25, 2003 19:59 UTC (Thu) by hazelsct (guest, #3659) [Link]

Why upgrade the kernel? If the old one works, keep using it. If you need a new one, just do:

apt-get install kernel-image-2.4.22-1-686

(or select it in dselect/aptitude/etc.).

This is supposed to be a feature of GNU/Linux systems: upgrade without requiring a reboot! When you need the stuff in the new kernel, then you get a new kernel.

The Great Package Management Experiment

Posted Sep 26, 2003 18:49 UTC (Fri) by ranger (guest, #6415) [Link]

Why upgrade the kernel? If the old one works, keep using it.

But if this applies to Debian, it applies just as well to Mandrake.

However, note that 3rd-party software (notably Win4lin) may want you to be running the default kernel, so I would expect a fair comparison to include a kernel update on both.

So, it looks like (according to the other poster who reckoned that an apt-get update would be necessary) Mandrake and Debian come out even?

Anyway, to the original author, please (especially with the Cooker HOWTO) refer to the more official documents available on the Mandrake Cooker Wiki

The Great Package Management Experiment

Posted Oct 3, 2003 16:52 UTC (Fri) by k8to (subscriber, #15413) [Link]

The answer is yes: dist-upgrade will sometimes upgrade your kernel. In most cases, the kernel upgrades do not happen without explicit request, but in a major changeover, you will get updated.

Clearly this will not take effect until a reboot.

The Great Package Management Experiment

Posted Oct 4, 2003 7:51 UTC (Sat) by marv (guest, #15720) [Link]

Your kernel will only be upgraded if you ask for it (i.e. by installing the
meta-package kernel-image-2.4 which always depend on the last 2.4 kernel).

The Great Package Management Experiment

Posted Sep 25, 2003 21:47 UTC (Thu) by daenzer (✭ supporter ✭, #7050) [Link]

He did the apt-get update before installing mplayer already. ;)

Seriously though, these days you can also use e.g. feta -u dist-upgrade, and it does everything in one step, including invoking sudo or your favourite root wrapper if necessary.

How about portage, or even autopackage?

Posted Sep 25, 2003 15:19 UTC (Thu) by alspnost (guest, #2763) [Link]

Obviously, this article, excellent though it was, has no mention of Gentoo's portage system. I would rate this pretty much on a par with Debian; there's a massive range of packages ready-to-go; and upgrading the entire system involves, as with Debian, just a pair of commands.

But beyond that, portage is aiming to cover some of the things you mentioned. Though Gentoo is source-based, future versions of portage should be able handle binary packages and source installation methods the same way.

Multiple concurrent versions of the same package are already supported, and as for universality, I believe portage is already being "portaged" (sic) to Mac OS X and BSD. Well, it's a start!

I work with Solaris, and I would dearly *love* it to have some of this technology; currently, it's an absolute pain to maintain.

Anyway, the future is either portage, or possibly autopackage - that looks like it could be a killer, if widely adopted.

How about portage, or even autopackage?

Posted Oct 3, 2003 7:35 UTC (Fri) by job (guest, #670) [Link]

I'm sorry, but Gentoos package system is pretty far from Debian's. (I say this is
a user who's been running both distributions for quite some time, and prefer
Gentoo for desktop work such as mplayer in the example.)

To start with, you need three different package tools as emerge in itself isn't
very capable. Then there's three or four different ways of masking a package,
so you may well have to go edit the package definition files (ebuilds) in order
to install stuff.

And since emerge in itself is lacking some features, there is simply no simple
way at all to do certain things, such as upgrade a library AND all files that
depend on it. You have to script it or do it by hand.

I love Gentoo as a source distribution and an alternative to LFS (Linux From
Scratch), but if package management is your game, nothing can beat Debian.

How about portage, or even autopackage?

Posted Oct 3, 2003 9:53 UTC (Fri) by emj (guest, #14307) [Link]

Well Debian really has a lots of diffrents ways to install packages. You have to use apt-get, dpkg, apt-cache, aptitude or wajig to get everything you want to have. Debian really lacks a tool that will give a good unified interface, but that isn't the UNIX way.. ;-)

The Great Package Management Experiment

Posted Sep 25, 2003 17:00 UTC (Thu) by zooko (subscriber, #2589) [Link]

I use GNU stow on my Debian system, when I want to build something from source:

./configure --prefix=/usr/local/stow/bindlywhoop-v1.2
./make
./make install
cd /usr/local/stow
sudo stow bindlywhoop-v1.2

It doesn't do dependency management for you, but for some reason I rarely need it. Perhaps the things that I want to hack on and compile from source don't usually have dependencies.

The Great Package Management Experiment

Posted Sep 28, 2003 23:17 UTC (Sun) by torsten (guest, #4137) [Link]

./configure --prefix=/usr/local/stow/bindlywhoop-v1.2

This method is defective. The path is hard-coded into some of the libraries and binaries. When you move the directory to another prefix, the package will fail (some packages fail, some don't).

The Great Package Management Experiment

Posted Oct 4, 2003 14:11 UTC (Sat) by csh (guest, #15725) [Link]

The proper way to use something like stow is this:

% ./configure --prefix=/usr/local

When you install, you use this command:

% make prefix=/usr/local/stow/<package>-<version>

Then when you stow the program, it will have normal paths like you would expect.

If you aren't using a package with the GNU auto stuff, you'll have to do this step manually.

I used to maintain my own system, and a set of patches for different packages to handle the dual nature of a "stowed" install.

Package manager features

Posted Sep 25, 2003 17:53 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

*Install programs into subdirectories.

What do you mean by this? Installing packages into /this/is/my/fave/bin/ will probably fail because they aren't found, or they don't find their pieces

*Recognition of source-installed apps (non-packaged, non-managed).

Please tell how you want the system to find out that of the 300 files changed today, 20 are in one package, 35 in the other, most of the rest is leftover junk from building, and then there are unrelated changes.

*Soft symlink into the file system (prevents overwrites, etc).

Dunno what you mean here. If you symlink, the original link is gone.

*Self-contained installation - no reliance on a script server.

What does this mean?

*Universality - should work on many *NIX.

Just compile RPM for it, and be done. Just the (very minor) issue of getting all *NIX people to use RPM for packaging... Debianites will come screaming for your hide, for starters ;-)

Package manager features

Posted Sep 28, 2003 23:26 UTC (Sun) by torsten (guest, #4137) [Link]

You obviously have no major experience with relinking or scriptable package installation. I imagine this is because you have not discovered the problems associated with rpm package management. Stay with your RPM's and be happy. All of the points above are understandable by any Linux techie who has dealt with system management issues, packaging, and package management. They are also valid points, which indicate the weaknesses in all the current package management systems.

Package manager features

Posted Oct 4, 2003 8:06 UTC (Sat) by marv (guest, #15720) [Link]

**Install programs into subdirectories.

*What do you mean by this? Installing packages into /this/is/my/fave/bin/ will
probably fail because they aren't found, or they don't find their pieces

Mainly for user-land installs.

Scoring apt-usage on RH and on SuSE

Posted Sep 26, 2003 0:13 UTC (Fri) by ladislav (guest, #247) [Link]

In SuSE's case, I deducted two extra points for technical reasons, which were left out from the article due to space limitations:

1. Installing apt on Red Hat required download and manual installation of only one package (apt), while on SuSE, it required three packages (apt, apt-libs and lua).

2. While installing MPlayer, apt reported that it needed a Java package to satisfy the already installed OpenOffice package. I didn't see the connection between MPlayer and Java, nevertheless, I was only allowed to install MPlayer after installing Java first.

I am sorry if the article seems biased. Like everybody else, I also have my favourite distribution, but I did try my best to be as impartial as possible. If any bias still shows, it's unintentional.

Scoring apt-usage on RH and on SuSE

Posted Oct 2, 2003 17:43 UTC (Thu) by jasonlotito (guest, #15665) [Link]

I'm just trying to figure out why you only reviewed YOU, and avoided YaST. Indeed, you went ahead an installed apt-get for some reason when YaST works fine. In fact, YaST is perfectly capable of handling non SuSE distributed RPM's, such as those from usr-local-bin.

Upgrading is just as easy too. It's just a matter of getting the new CD, putting it in, and upgrading.

Your mark of 6 against SuSE is really just unfair. Great, so SuSE's unofficial apt-get package manager is a 6. But what about YaST, the default, and much better package manager?

Putting this into perspective, Debian would receive a low score because when I tried to install YaST, Debian gave me problems.

Scoring apt-usage on RH and on SuSE

Posted Nov 29, 2003 2:27 UTC (Sat) by agill (guest, #17301) [Link]

"In fact, YaST is perfectly capable of handling non SuSE distributed RPM's, such as those from usr-local-bin."

I was talking to a SuSE employee on IRC and I was told that YaST can't use 3rd party software repositories and that I should try to stick to SuSE provided RPMs or use something like apt for suse. I like to create my own RPMs for certain software and store them on my local ftp server. Could you please provide some links to documents describing how to coerce YaST into displaying my custom software from my local server?

"Upgrading is just as easy too. It's just a matter of getting the new CD, putting it in, and upgrading."

Hmm but what if I want to update a remote server? I don't have anything against SuSE but that's one thing I really like about Debian. Two commands have allowed me to upgrade remote computers from one version of the OS to another.