[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How much redundancy?

Fairly often I've seen ITPs or package sponsorship requests followed up
to by questions about redundancy against packages already in Debian.
Thus, I'm curious -- what degree of redundancy is acceptable or
desirable?  As big as a Debian distribution is, there's unavoidable
overlap.  It's easy to understand, say, choosing one particular ping
implementation from a couple of functionally near-identical
possibilities.  However, one package could functionally be entirely
provided by another, while still desirable by way of being smaller,
simpler, written in Python or whatever.  It seems reasonable to provide
redundant packages when users could have a credible desire to use one or
another (e.g. one of the half-dozen minimalist windowmanagers.)  Is
there a reigning convention?

The example that got me to wondering: I was considering packaging Namp,
formerly Apache::MP3 (namp.sourceforge.net).  Namp turns Apache into a
frontend for an MP3 collection with streaming and various related
features.  Functionally, it's largely redundant with mod_mp3, already in
Debian as libapache-mod-mp3.  Indeed the latter is more featureful in
some respects and can't really be said to be inferior in performance or
most other qualities.  However, they're wholly separate projects, their
implementations are different, and their interfaces with humans are at
least as different as, say, KDE and GNOME apps.  Namp is a bit easier on
the admin side IMO, but that's splitting hairs.

Devin  \ aqua(at)devin.com, 1024D/E9ABFCD2;  http://www.devin.com
Carraway \ IRC: Requiem  GCS/CC/L s-:--- !a !tv C++++$ ULB+++$ O+@ P L+++

Attachment: pgpJT4Go7n1YE.pgp
Description: PGP signature

Reply to: