Organizational Effects? [LWN.net]

Organizational Effects?

Posted Sep 25, 2003 2:39 UTC (Thu) by stevenj (subscriber, #421)
Parent article: The Great Package Management Experiment

Thanks for the article; it's nice to see such a systematic comparison. The "system upgrade" step is a bit hard to compare, of course, since the magnitude of the upgrade would vary for the different systems; perhaps the number of packages upgraded should have been included as a metric.

What I would like to see would be an experiment that measures organizational effects: the degree to which different packagers and package sites for a distro are centralized/coordinated. (I suspect that this has a greater practical impact than the technical differences between packaging tools.)

For example, pick 100 randomly selected packages from freshmeat.net (or similar), and see how long it takes you to find packages and install them (verifying that they work) on the different distros. (Of course, the package versions might differ; you could collect statistics based on the age of the packages available from the "default" sites, if any, plus the time to find and install the most recent versions.)

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