Revisiting RPM Package Management [LWN.net]

[This article was contributed by Ladislav Bodnar]

The anticipated announcement by Red Hat, Inc. about the future direction of the Red Hat Linux Project, originally scheduled for publishing early this week, was rudely postponed by the imminent arrival of hurricane Isabel in North Carolina. But even as preparations for the potential natural disaster took precedence over writing code, Red Hat still found time to update us on the progress. "We are excited to announce that we are working on an alliance with another well-known provider of Red Hat compatible packages", claims the updated Red Hat Linux Project page. It also promises to release a full announcement, and possibly a new Red Hat beta, on Monday, September 22.

One of the more exciting aspects of this change in direction for Red Hat Linux is introduction of an advanced RPM package manager into the distribution. Traditionally, a lack of one, especially a lack of one with the ability to auto-resolve dependencies, has been a sore point with many users of Red Hat, SuSE and most other RPM-based distributions who often found it frustrating to install or upgrade software. In recent years, many settled on using a third-party application, such as apt-get, apt4rpm or yum, but nevertheless, Red Hat and SuSE's reluctance to provide and support any of them was not appreciated. Luckily, the Linux world is changing fast and Red Hat no longer sees the traditional retail boxed sets as a major income provider. This was possibly one of the reasons for introducing "yum" into Red Hat Linux.

Before we get to explore the wonderful world of advanced package managers, let's take a look at the RPM. Often incorrectly referred to as "Red Hat Package Manager", the abbreviation actually stands for "RPM Package Manager", a recursive acronym often found in UNIX and Linux worlds. "The RPM Package Manager (RPM) is a powerful command line driven package management system capable of installing, uninstalling, verifying, querying, and updating computer software packages.", asserts the rpm.org website. The format was developed by Red Hat Inc. at some point in mid-nineties, when the Linux distribution market was utterly dominated by Slackware Linux and its TGZ package format. TGZ packages were (and still are) nothing more than simple compressed archives of individual files along with a script that places them into correct directories during installation. When RPM arrived, it was seen as a huge improvement over TGZ. It is not unreasonable to conclude that the RPM package format played a crucial role in the dramatic swing in Linux market share - away from Slackware and towards Red Hat. In the following years, the RPM package format was also adopted by SuSE, Mandrake, Caldera, Turbolinux and many other distributions.

As wonderful as RPM was compared to TGZ, it was the non-commercial Debian project which sprinted ahead in the package management game in March 1999 with the introduction of APT in Debian 2.1. APT is a front-end to Debian's own package management with an ability to resolve software and library dependencies. This proved to be a very successful tool and the RPM package manager was soon to be subjected to crude jokes by Debian users and developers. However, they only lasted till December 2000 when Conectiva Linux ported APT to create apt-rpm and incorporated it into its own distribution. Many other RPM-based distributions followed suit and apt-rpm was soon spotted in projects ranging from Russia's ALT Linux to Japan's Vine Linux. Confidence in RPM was slowly returning into the world of Linux users - except for the users of the Red Hat distribution who will have to wait until late this year before they can enjoy supported advanced package management with dependency resolution.

Those of you who monitor the Red Hat beta mailing list or the Red Hat development branch called Rawhide, have already noticed the presence of "yum" among the long list of packages. What is "yum"? "Yellow dog Updater, Modified is an automatic updater and package installer/remover for RPM systems. It automatically computes dependencies and figures out what things should occur to install packages. It makes it easier to maintain groups of machines without having to manually update each one using rpm." Dependency information is extracted from RPM header files, which list library and software requirements, as well as conflicts with other packages. It is simple to use with commands such as 'yum check-update', 'yum update' and 'yum install <packagename>'.

Useful as yum is, many Red Hat veterans have already standardized on apt-get, with its Debian-like commands of 'apt-get update', 'apt-get dist-upgrade' and 'apt-get install <packagename>'. However, apt-get has not been spotted in Rawhide, so those who prefer to use it will have to continue relying on an unofficial version. We have seen very little technical information about Red Hat's reasons for favoring yum over apt-get, but this is something that will no doubt be explained in the coming weeks. Both apt-get an yum are supported by the Fedora Linux community project, which is one of the largest and most popular third-party repositories of Red Hat compatible RPM packages, while the other main repository at Fresh RPMs only provides apt-enabled package sources.

With Mandrake's own 'urpmi' package management and now Red Hat's inclusion of 'yum', SuSE Linux is the only major Linux distribution still stubbornly refusing to provide and support any apt-like, dependency resolving package management tool. How long before it too succumbs to the power of modern software management?

(Log in to post comments)

Revisiting RPM Package Management

Posted Sep 18, 2003 2:41 UTC (Thu) by ladislav (guest, #247) [Link]

SuSE's YaST (or more specifically YOU - YaST Online Update) does indeed resolves dependencies from its own distribution and officially sanctioned updates. However, it does not provide a means to add third party repositories with package updates or other software not supplied by SuSE. As such, you cannot use YaST for updating say KDE to the latest version; you have to do it either manually or install a third-party package management tool, such as apt-get. Please correct me if I am wrong.

Revisiting RPM Package Management

Posted Sep 18, 2003 9:48 UTC (Thu) by petebull (guest, #7857) [Link]

I correct you.

With SuSE-8.2 one can add additional package sources. I have installed
SuSE-8.2 via FTP and later added the installation source for KDE-3.1.3
and Yast2 installed the packages for me.

Have a look at
http://ftp.gwdg.de/pub/suse/i386/supplementary/KDE/update_for_8.2/yast-source/

Revisiting RPM Package Management

Posted Sep 18, 2003 10:28 UTC (Thu) by leandro (subscriber, #1460) [Link]

> what exactly does all other distro's dependency resolution provide that SuSE's yast2 does not?

Freedom. Yast is proprietary.

Revisiting RPM Package Management

Posted Sep 18, 2003 11:30 UTC (Thu) by RobDavies (guest, #9930) [Link]

YaST license only fails the OSI Open Source definition, because it does
not permit re-distribution for a fee. Full source is provided and
modifications are permitted, so simply labelling it 'proprietary' is an
over-simplification.

Revisiting RPM Package Management

Posted Sep 18, 2003 18:25 UTC (Thu) by vblum (guest, #1151) [Link]

> Freedom. Yast is proprietary.

1) you are right, Freedom would be nice. Why? It is a key mistake of "the Linux industry" to not settle on a common installation / sysadmin interface / GUI framework. This repeats the fragmentation of unix (if you extrapolate a few years ahead). It's extremely annoying that you have to relearn all that stuff for every single new distribution. This will ultimately scare users back to Windows (one distributor = relative consistency; monopolies are great for that).

OSDL might be the place to settle that issue; it may seem trivial, but having to administer RH, SuSE at the same time is really annoying due to lack of consistency between them in little things.

2) Freedom is not a requirement for a working package management system, though - which is the topic of the article. SuSE does have that, as far as end users are concerned.

cheers

Revisiting RPM Package Management

Posted Jan 6, 2004 17:49 UTC (Tue) by leandro (subscriber, #1460) [Link]

> Freedom is not a requirement for a working package management system, though - which is the topic of the article. SuSE does have that, as far as end users are concerned.

For me and for thousands other freedom is a requirement. Just because one's an end user it doesn't mean one abdicates from freedom.

Don't be misled

Posted Sep 18, 2003 5:15 UTC (Thu) by ncm (subscriber, #165) [Link]

It is a fundamental error to equate a ported apt-get with Debian's package management. Most of the value of Debian's packaging isn't in apt-get at all, but lies rather in Debian's packaging policy and its enforced application to the contents of packages. Apt-get just takes advantage of the enforced policy. Without that policy, apt-get is a hollow shell; it can automate downloading, which looks nice, but can't prevent problems of incompletely described package interactions.

The reason this matters is that users of apt-get and its offshoots on other distros might come to believe that Debian, raided for its convenient apt toolset, has nothing unique left to offer. On the contrary, for example, Debian's more careful library naming policy eliminates most library version problems. On other distros you must manually override the package manager, which can't track multiple library versions, and in so doing you are likely to break your installation. It is almost never necessary to override the Debian package manager's judgment; in six years I have only done so while purging third-party packages that turned out to be faulty.

A Debian system can be fully upgraded by the package manager from one major release to another without a dangerous "reinstall". Most Debian users only ever install once on any given machine, and upgrade incrementally at need, without rebooting.

Anyone who wonders where the hundreds of volunteers have applied their efforts, instead of delivering a flashy UI installer, should consider that they have not been idle. Other distros can lift apt-get, but they can never afford to duplicate the deep work on system coherence that has gone into Debian.

Don't be misled

Posted Sep 18, 2003 5:22 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

I've successfully updated Red Hat distribution versions using only apt-get (using several separate steps; I wouldn't dare try just one dist-upgrade on either a Red Hat or a Debian system), and I've also had more problems with doing the same on Debian than Debian advocates claim.

The Debian people are more careful and organized, but they do make mistakes.

Don't be misled

Posted Sep 18, 2003 6:08 UTC (Thu) by Ross (subscriber, #4065) [Link]

I agree. RPM should be compared to DEB, not to apt. Of course RPM also
fails to support all the nice features of DEB and it was introduced long
before apt. It may predate RPM, I don't remember.

Don't be misled

Posted Sep 18, 2003 10:31 UTC (Thu) by leandro (subscriber, #1460) [Link]

> Of course RPM also fails to support all the nice features of DEB and it was introduced long before apt. It may predate RPM, I don't remember.

AFAIR deb was conceived before rpm but saw the light of day after: Red Hat didn't want to collaborate with (and wait for) the right thing, so they got an access of NIHS and went their own way with their own half-baked stuff, thus fragmenting the community.

And here they go again with yum over apt. Sad.

Don't be misled

Posted Sep 18, 2003 14:46 UTC (Thu) by skvidal (subscriber, #3094) [Link]

Hi,
I don't work for red hat. I work for duke university. I'm a sysadmin there.
I'm the author of yum. I think one of the reasons red hat has put yum in rawhide before apt (and note, it's just BEFORE, it's not INSTEAD) is that yum, is about 7000 lines of code, while apt is 40000+. Also yum is in python which we all know red hat is far more comfortable in.

I don't think this has anything to do with denying debian or NIHS b/c they didn't invent yum.

Also, if you'd look closely at up2date in rawhide you'll notice that is has support for both yum and apt-rpm repositories.

-sv

Don't be misled

Posted Sep 18, 2003 15:08 UTC (Thu) by DancingProg (subscriber, #4816) [Link]

Thank you for the info and the great tool.

Don't be misled

Posted Sep 18, 2003 22:36 UTC (Thu) by hazelsct (guest, #3659) [Link]

Indeed, thank you for the great tool, the difference in line count is impressive.

Debian's decision to use C is a sound one however, because python would bloat the base system significantly. apt-get in stable on i386 is about 153 kB (not kiB); python alone is about 518 kB. So as Debian and derivatives (e.g. Familiar) are installed on embedded systems from iPaqs to routers, the significantly smaller base system -- without sacrificing automatic dependency management -- is an advantage.

But perhaps RedHat is not concerned with such markets.

Don't be misled

Posted Jan 6, 2004 17:38 UTC (Tue) by leandro (subscriber, #1460) [Link]

> I think one of the reasons red hat has put yum in rawhide before apt (and note, it's just BEFORE, it's not INSTEAD) is that yum, is about 7000 lines of code, while apt is 40000+.

This has more to do with their homegrown RPM that they decided to use instead of help finishing dpkg at the time.

Don't be misled

Posted Sep 18, 2003 7:01 UTC (Thu) by Frej (subscriber, #4165) [Link]

Like the not so clever naming of libXML perl module?
'libxml-libxml-perl'

Re: Don't be misled

Posted Sep 18, 2003 7:56 UTC (Thu) by tarvin (subscriber, #4412) [Link]

I've recently considered switching to Debian, because of the uncertainties surrounding the future of Red Hat's free distribution, and because of the very short support-lives that have been announced for the free versions of Red Hat's distribution.

Unfortunately, it seems that digital signing of deb-packages hasn't proceeded significantly. In effect, Debian still doesn't offer pgp-signed packages.
In my dark opinion, it's a simple matter of time before a major Debian mirror site is cracked and trojan-infected software is distributed. Without digitally signed packages, I wouldn't have much of a chance to detect such a situation.

Does anyone know if digitally signed deb-packages might be realistic with a forseeable future?

Re: Don't be misled

Posted Sep 18, 2003 9:38 UTC (Thu) by rganesan (subscriber, #1182) [Link]

Individual Debian packages are not signed but a Debian archive/mirror is quite safe. First, any upload of a package to the primary FTP site is digitally signed (not the package itself, but the package "description"). Next, debian signs a Release file which contains the md5sum of the "Packages" file which contains the list of all packages. Finally, the Packages file contains md5sums of each individual package. See
http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign

Don't be misled

Posted Sep 18, 2003 22:23 UTC (Thu) by hazelsct (guest, #3659) [Link]

Indeed. Debian's network of volunteer package maintainers is the envy of companies like RedHat and Mandrake, which is why they are trying to switch to the Debian model. In the end, though, they're just Debian Wannabees, and their corporate-centric governance model is doomed to fail. Bwa ha ha ha ha!

The Debian "Model"

Posted Sep 19, 2003 3:47 UTC (Fri) by lovelace (guest, #278) [Link]

Mandrake isn't trying to "switch to the Debian model". Mandrake has been put together by
volunteers in the Cooker project for quite a while. While they are putting together a
community with the Mandrake Club, packages created there are not included in the base
installation.

Debian Packaging Policies

Posted Sep 19, 2003 3:38 UTC (Fri) by lovelace (guest, #278) [Link]

You're right, Debian's packaging policies add a lot to how well it can deal with things like
library version conflicts. That's why Mandrake adopted the same policies with version 8.0. I
would love to see Red Hat do something like this as it really does simpilify the problem of
multiple library packages without doing hacks like saying that this packages that was
formally named foo is now foo1.0 and the current package foo is now version 2.0.

One other thing of Debian's Mandrake uses is the Debian menu system. This allows the
user to have the same menu system no matter what desktop they use (KDE, GNOME,
WindowMaker, etc...).

Most of Mandrake these days is put together by volunteers working on the Cooker project. I
would suggest that, although not as big as Debian, they have done at least as good a job as
Debian has. Because of how open source/free software works, they don't have to
"duplicate" Debian's work. They can follow their example and the example of others and
pick the parts that work and leave the parts that don't. The nice thing is, though, is that
Debian can do the same. As a community, any work we do can help each other. That's one
of the things that makes open source/free software great. I'm glad to see that Red Hat
finally seems to be embracing the community more and I wish them all the luck.

What RPM stands for

Posted Sep 19, 2003 3:50 UTC (Fri) by lovelace (guest, #278) [Link]

Michael Tiemann addressed this recently when he spoke to the Triangle Linux Users Group (August 2003 meeting). RPM was consciously renamed to avoid trademark problems with other people using it. Personally, I think that was very nice for them to do. While I don't use Red Hat myself, I certainly respect them and what they've done and thank them very much for their many contributions to Linux.

What RPM stands for

Posted Sep 19, 2003 20:11 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

RPM does not, in any common usage, stand for anything. Like most acronyms, it is a word in its own right and means much more to the reader than any 3 word phrase that the letters might stand for. In other words, RPM is an acronym, not an abbreviation.

"Red Hat Package Manager" is the etymology of the word. You can't declare the etymology to be different after the fact.

Still, people like having underlying phrases for acronyms, just for fun.
They make them up even for words whose etymology is not acronymal at all. In that spirit, we have whimsical things such as "RPM Package Manager."

Revisiting RPM Package Management

Posted Sep 18, 2003 22:26 UTC (Thu) by hazelsct (guest, #3659) [Link]

You mean like Debian already has?

apt-get build-dep packagename

will automatically download the package's source, along with all of the packages necessary to build it, and then build the package. It always works, because if it doesn't, it's a release-critical bug, and the package is excluded from the subsequent stable release. Such strictness is crucial in Debian because packages for the ten non-i386 architectures are built this way.

Revisiting RPM Package Management

Posted Sep 25, 2003 7:40 UTC (Thu) by k8to (subscriber, #15413) [Link]

From the apt-get manpage:

       build-dep
              build-dep causes apt-get to install/remove packages in an attempt to
              satisfy the build dependencies for a source packages. Right now vir-
              tual package build depends choose a package at random.

Is the provided documentation incorrect?

My reading is that apt-get build-dep simply gets the build requirements for a package, without building or installing it. This is also my experience.

In order to actually build and/or install a package, dpkg-buildpackage may be used directly, or it may be invoked by the third-party apt addon tool apt-build, which is not part of the base apt distribution.

Without this addon, one must use the strangely phrased 'apt-get source <packagename>' which sadly spews several files into the current directory, and then manually invoke the dpkg-buildpackage tool to generate debs which may be then installed with dpkg. Unfortunately, these packages will be considered nonpreferentially to the standard packages by apt, which will simply "upgrade" them to the nonlocally generated versions. I have yet to discover a nice solution to this sticky bit. Putting the pakages on hold is not to my liking.

-josh

Revisiting RPM Package Management

Posted Sep 18, 2003 14:52 UTC (Thu) by ladislav (guest, #247) [Link]

It seems that many readers consider my claim that SuSE does not have an advanced package manager incorrect. Admittedly, after reading all the comments above I would not dare to assert that claim again. However, and before I admit complete defeat and lack of knowledge, please consider these two points:

1. By "advanced package manager" I meant a package manager which would enable to add third-party repositories, after which the user could continue to expect flawless installations of packages from those repositories. Let's take a package not readily available in SuSE 8.2, such as BitTorrent or Webmin. How would one install those with YaST? Can anybody explain the process? Debian's apt-get and Mandrake's urpmi make this very simple; is it the same with YaST? Otherwise one could claim that Red Hat's up2date is an advanced package manager with dependency resolution, which would be a fair comment. But up2date is hardly a satisfactory solution - if it was, there would be no place for "yum".

2. Probably the main reason for my claim that there is no advanced package manager in SuSE is the regular appearance of apt-related questions on SuSE's mailing lists. This would seem to indicate that many people do in fact install apt4rpm on SuSE Linux. This I find mysterious given some of the above posts - if YaST can handle package dependencies, update software to newer versions and install packages from third-party repositories, why would anybody want to use apt4rpm? If you know the answer, please enlighten me.

As many readers have correctly guessed, I am not a regular SuSE user. I have, however, installed every SuSE version since 7.2 (I am writing this from SusE 8.2) - mainly to see what's new and to get a general feel for each new release. I usually give SuSE a few hours of attention after installation (I honestly believe that SuSE Linux is a superb product), but it isn't my main production distro. As such, I don't have a detailed knowledge of all its intricacies. That's why a forum like this is an excellent place to learn from experts and I do appreciate all your corrections. Please keep them coming.

Revisiting RPM Package Management

Posted Sep 18, 2003 15:32 UTC (Thu) by duck (guest, #4444) [Link]

Hello,

as I said - there are hardly any third party repositories. SuSEs yast handles
dependencies automatically, but not if the dependency can not be resolved with the
packages available within known repositories.

Have a look at packman.links2linux.de.

There you will find lots of updated multimedia rpms for different SuSE versions. If you
select one package, YAST is launched and you can install it directly from the web - if
there are no dependencies that can only be solved by installing another third-party
rpm. Since this is hardly the case with multimedia rpms, the feature is not very useful
for these rpms.

Nevertheless, yast detects dependecies, tries to solve them and even allows you to
force the installation of a package. The capabilities are there, but not the repositories.

Cheers

duck

Revisiting RPM Package Management

Posted Sep 19, 2003 11:15 UTC (Fri) by RobDavies (guest, #9930) [Link]

Quotes from the article :

"especially a lack of one with the ability to auto-resolve dependencies"

"SuSE Linux is the only major Linux distribution still stubbornly
refusing to provide and support any apt-like, dependency resolving package
management tool"

Talk about rpm based distro's failing to resolve dependencies is riddled
through this article. OTOH, I find no mention of 3rd party repositories,
until your introduction of what you mean by "advanced package manager" in
the comments section. The whole article's emphasis is actually on
auto-depends resolution, so it is natural for the reader to be misled, by
the statements made.

The article should be retracted and replaced with a useful fact based one,
maybe including a discussion on the pro's & con's of 3rd party
repositories. It is now clear that RedHat is in fact the last leading
distribution to add, these features, so the last paragraph singling out
SuSE, should be particularly embaressing, they should receive an apology.

I think the reason why apt4rpm is popular under SuSE is a combination :

1) Media "Buzz", everyone knows apt-get <package> installs a package.
There have not been many (any at all?) articles on the net, about command
line YaST features, probably because it's SuSE specific, and reviewers
traditionally demand and review GUI administration, not fully appreciating
the power of the commandline. YaST's dependency resolution is very, very
old news, so is not reported. User's tend not to read manuals, so even
documented features may be ignored, for some other method which has more
publicity.

2) 3rd party package providers may specify apt, it's simpler for them to
standardise on one format, rather than learn new distro-specific ones.

3) YaST2 has been under constant development since it's introduction in
7.0, the online updating was not initially implemented particularly well,
and SuSE has not emphasised a committed stable repository format, nor
particularly encouraged 3rd party repositories.

Very many commercial server installations, want stability and
accountability for the core set of system features, with a few key
applications installed. Then QA features like cryptographic signing, and
known suppliers of packages, to a known base release, are more important
than convenient add-ons from 3rd parties.

A standardised format for these competing implementations, YaST, uprmi and
yum, might be interesting as an extension to LSB, the initial strategy of
fixed & stable library versions present, appears to be unrealistic and
ignored in practice. As some Debian using readers point out, strictly
adhered policies on library versioning is important.

SuSE Linux 9.0

Posted Sep 18, 2003 20:27 UTC (Thu) by vblum (guest, #1151) [Link]

Interesting, I had been looking for the date - thanks for all your efforts (not just that one)!

Revisiting RPM Package Management

Posted Sep 18, 2003 17:32 UTC (Thu) by mongre26 (guest, #4224) [Link]

Yum is technically superior to the port of Apt-get to RPM for several reasons most listed on the Duke site had the author visited it.

http://linux.duke.edu/projects/yum/

From the Yum Site

"Every rpm has a header. That header contains a complete file list, package descriptions, lists of what features/libs it provides, lists of what it requires, what it conflicts with etc. In order for rpm to make a decision about what an rpm will need to be installed it needs the information in the header. Fortunately, this is all it needs. Many other updating tools use an index created of that information. They take the important information and send it to the client and use that to determine what should be installed. What Yum does is to copy the header from the rpms on the server (called a repository, just an HTTP or ftp server, nothing fancy or custom), then the client part of yum uses those headers to determine what needs to be installed/upgraded/erased. The benefit of using the rpm header is that yum can then rely on rpm to determine what should happen, because all the information is in a format native to rpm so no custom dependency calculation code is required. Another benefit is that this makes yum quite fast. And finally, by not writing custom dependency code yum keeps from reinventing the wheel and writing a parallel dependency engine to rpm. Rpm does all the hard work."

Basically instead of writing a whole lot of C code to do dependencies Yum makes use of what is already there via Python. It is just putting the pieces together that were there all along.

I use yum extensively to manage updates and packages on the dozens of systems that I manage. It is easy to work with and fairly reliable. I am very glad that it will start to come standard in Redhat.

urpmi and Mandrake (and the Mandrake community)

Posted Sep 18, 2003 20:48 UTC (Thu) by ranger (guest, #6415) [Link]

It's interesting how good ideas seem only to be noticed when they are adopted by a large company ...

Firstly, in your article, you discuss apt4rpm and yum, but only mention urpmi in passing.

You noted that apt made it's appearance in Debian in March 1999. urpmi made it's appearance in Mandrake's stable release in 7.0 (IIRC), which was in early 2000 (at least 6 months before apt4rpm). urpmi is more functional than apt4rpm, and there have been an ever-increasing number of features and improvements. urpmi now has key management (allowing you to assign keys to certain urpmi media - in essence trusting certain identities for certain packages) and retreival, support for small transactions, support for parallel installation on multiple hosts. urpmi has been capable of the much-touted "apt-get dist-upgrade" since at least 9.0->9.1 (I did a number of upgrades with no problems), and updating to 9.2 will now be trivial (no more difficult that with apt on Debian- many of the same issues apply though).

Secondly, now that Redhat is suddenly more "community oriented", they get all this coverage for a decidedly bland page (mostly listing mirrors), while Mandrake has had cooperative development, with active involvement of the community for a significant time.

We don't see anyone mentioning the cooker wiki, or the fact that a number of important packages in the main distribution are maintained by non-Mandrakesoft-employed community members (note that addresses @linux-mandrake.com are addresses for community members, addresses @mandrakesoft.com are for employees).

Also, you will notice with the release of 9.2 that a lot of Java packages are available for the distro, thanks to the efforts of the Jpackage project. We could also mention the PLF.

Redhat still has a long way to go before they have a real development community.

And still we find that news is only news if Redhat does it, for some reason it's not news a year or two earlier when Mandrake does it ...

Debian continues to sprint ahead

Posted Sep 18, 2003 23:26 UTC (Thu) by hazelsct (guest, #3659) [Link]

A poster above mentioned the Debian maintainer network and resulting quality of packages as the major advantage which makes Debian seem so much better at upgrading than, say, RedHat.

But this is only part of the story.

With Debian 2.1 came apt, with its legendary dependency management capability. The quality of the dependency relationships throughout the 9000+ packages in stable and 13,000+ in unstable is, of course, the result of the hard work of the Debian maintainers.
2.2 (IIRC) saw the introduction of doc-base, which links all installed documentation from a single unified index. There are two front ends: a local HTML tree built by the package dhelp, and a tree built in CGI for a web server by the package dwww. The completeness of the doc-base index is, of course, the result of the hard work of the Debian maintainers.
The Debian menu system has all of the GNOME and KDE and just about all other X11 applications in a single hierarchy which is linked to the menu systems of GNOME, KDE, Enlightenment, XFCE, GNUStep, and even FVWM2, so all applications are available in all environments. The completeness of this index is, of course, the result of the hard work of the Debian maintainers.
The debconf configuration management system asks the admin configuration questions before packages are installed/upgraded, and constructs the configuration files accordingly during installation. More significantly, these answers are preserved to construct new conffiles on upgrades, automatically preserving admins' preferences across conffile format changes. Furthermore, the new HTTP backend allows an organization to standardize management of debconf options for a large number of machines. The extensiveness and thoroughness of package customization which debconf makes possible is, of course, the result of the hard work of the Debian maintainers.

So much of Debian's strength is about enforcement of quality standards. But it is also about continuous improvement in the packaging infrastructure to make life ever easier for admins.

Just as the Linux kernel guys can more easily make needed changes to kernel interfaces than, say, Windows kernel people, because the drivers and user-space tools which work with them are free, so Debian's infrastructure can adapt as necessary to preemptively provide the highest quality and simplest administration, because the thousands of packages which ship with Debian are all free.

So now RedHat has yum, SuSE's YAST does some of teh same, and GNOME has scrollkeeper, and GNOME and KDE have their menu systems, and there's even an effort to do debconf without Debian (can't find it just now, I think it's on SourceForge somewhere). But each of these is particular to its little universe, e.g. GNOME doesn't see the KDE documentation and vice versa, and what package support is there -- or will there be -- for this new son-of-debconf? And just as these guys are trying to copy Debian features, RedHat and Mandrake are rapidly trying to remake their package maintenance paradigm in the image of Debian's...

So you can wait for all these people to reinvent the Debian wheel, or you can just get Debian -- or one of its more easily-installed versions (Knoppix, Progeny, Lindows...) -- and enjoy the fruits of the hard work of the 1100+ Debian maintainers right now.