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:
pgpUuh6nQ77kx.pgp
Description: PGP signature