Re: duplicates in the archive
On Sun, Jun 24, 2012 at 08:48:48PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 18:45:54 +0000
> Bart Martens <email@example.com> wrote:
> > About allowing new packages in Debian in general : On the one hand you have a
> > point that Debian should not collect any free software, but on the other hand I
> > think that it is OK to have multiple implementations of the same/similar
> > functionality in Debian, and over time the popcon stats may indicate that a
> > newer package wins over an older package. It is, in my opinion, not always
> > possible to judge the potential of a package before it has been in Debian for
> > some time. Having competing alternatives in Debian is OK, even good, in my
> > opinion.
> The maintainer has to make that judgement, it's just one of the things
> maintainers have to do. popcon is no indicator here, it is about
> whether there is a bug in Debian, independent of this package.
Not only the maintainer but also the many users judge how useful a package is
in Debian. This judgement cannot always be made at ITP time. Popcon does
indicate how popular the package is, doesn't it ?
> I apply
> the same criteria to all my packages and I have and will continue to
> remove any which do not merit a place in a stable release.
I see no problem with removing packages that don't belong in a Debian stable
release. But weren't we talking about judging at ITP time on whether the
package is allowed to enter Debian ?
> What *quality* issue is meant to being fixed by a new package? If
> there's none, then the ITP is invalid and the package is without merit.
> Just like any other bug - if the submitter has just got it wrong (for
> whatever reason), the bug can be deemed invalid. Sometimes an
> improvement to the documentation can help others not make the same
> error, sometimes the docs are fine and it's just a mistake.
I don't think that an ITP is only valid if it fixes something in Debian.
Sometimes a package is worth entering Debian simply because it is good free
software, regardless of any alternatives already in Debian.
> Multiple implementations hurt the archive, waste ftpmaster time, waste
> QA time, waste wanna-build time, waste Debian resources, complicate
> transitions and often collect RC bugs. In short, the more duplicates
> there are, the higher the percentage of those duplicates which will
> go to rot in the archive, causing aggravation for everyone.
I'm not convinced that the above applies to "multiple implementations" more
than to simply "many packages". Neglected packages about should be removed.
That applies to any package in Debian, not only to "multiple implementations".
> Competition is useful, surfeit is harmful.
> If a new package does have merit compared to all the existing
> equivalents, then explain those merits and let your peers judge the
If there are sufficient volunteers who want to spend their time on packaging
the software and maintaining it in Debian, then why not let the users judge the
> The issue is to fix the problem in Debian, not just introduce a new
> package which fixes nothing.
The issue is to allow new packages a chance in Debian to rise above the
existing alternatives in Debian. This cannot always be judged at ITP time.