Re: duplicates in the archive
Neil Williams <codehelp@debian.org> writes:
> Whatever happens, there is no place for yet another duplicate of
> packages which already have multiple duplicates in the archive.
I think it's hard to defend the contention that the quantity of packages
has some strong relationship to whether or not those programs duplicate
the functionality of other programs. Surely it also depends on the type
of program, rather heavily.
For example, I'm sure that we have more than 42 different programming
languages in the archive, so obviously we don't need Java, right? You can
do all the same things in C++. Or hey, let's pick one of either Perl or
Python; they can both do the same things.
I can definitely come up with more than 42 different ways to write an
editor, all of which may appeal to different people, different tasks, or
different work styles. But hey, I like Emacs, which clearly does
everything that vi can do, so away with vim! And nvi just duplicates vim!
We probably don't need 42 different ways to find duplicate files on local
disk, since that's a relatively clear and well-defined task and there's
only so many ways to go about it (and each implementation could probably
gain the features of the others). But window managers are fundamental to
one's style of interaction with the computer, and there are *huge*
differences between them. A tiling window manager is not interchangeable
with a desktop environment, which in turn is not interchangeable with a
window manager designed to be operated without a mouse, or one that's
optimized for a particular class of accessibility issues. And that's not
even getting into the window managers that are used primarily because they
embed a particular scripting language that people want to use to automate
their windowing actions.
By all means, let's get rid of packages that really do only offer subsets
of functionality of other packages. But UI is part of functionality, and
a different UI *is* a different feature. By all means, let's get rid of
poorly-maintained packages. But if someone finds a package that does
something in a way that nothing else does and that fits them, and they're
able and willing to take care of it, having a place for those is one of
Debian's strengths. We should be improving our tools and management
techniques for handling large numbers of packages, including for retiring
them when they're not being maintained, not trying to reduce the variety
and depth of the distribution.
And as sympathetic as I am to the concern about RC bugs in packages that
are already in the archive, I suspect it's rather rare that fixing random
RC bugs in other people's packages is the compelling, fun thing that gets
someone involved in doing Debian development. I know it happens, but I
bet more people join the project the way that I did: there's some specific
piece of software that they want packaged for the distribution they
already use, so they package it, and from that learn how to package, and
from that branch out into helping with other parts of the distribution.
Getting one's own package into the distribution is a really awesome
feeling. I don't think it's good for the growth of the project, or for
attracting new contributors, to put too many roadblocks in the way of
someone feeling that.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: