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

Re: [PROPOSAL] Archive audit, cruft removal, unmaintained packages



Ben Collins wrote:
> This group will go through the archive (either manually or using
> internally created scripts) and generate detailed lists of dangling
> source/packages and post them for removal via the BTS and/or direct email
> to the archive maintainers.

This is not necessary.  We have such scripts, we run them
occasionally, and clean up some packages.  We just haven't had much
time lately.  Filing bugreports with this same information will just
add more work to the process.

The main problem with such cruft is often, what are we supposed to do
about it?  We even have a bugreport asking *not* to remove libstdc++2.8.
And there's the libjpeg situation... it is entirely unclear which of
the libjpeg packages are supposed to exist, and the maintainer doesn't
reply to my mail.

It might be good to put a note in the Shared Library policy that makes
the library maintainer responsible for the transition to a new major
library version.  Simply uploading a new version with changed package
names is the usual course, and it puts the problem in our lap.

> They will also generate lists of obsolete and
> unmaintained packages that are in the archive (the age of innactivity of
> maintainership to be determined by a set time length and attempts at
> contacting the last known maintainer for a defined amount of time).

This could be useful.  Some proposals have been floating around for
nonintrusive maintainer pings (i.e. using such information as can be
collected automatically), and they will be a benefit.

> Some of these packages could be put into a new directory called
> old-obsolete/, this may be in binary form or source only (not sure
> which would be better), others may simply be removed completely from
> the archive.

We have project/orphaned for that, it's source only.  The only package
I've ever seen come back from project/orphaned was apsfilter, though,
and that one's about ready to die again.  I think that the previous
stable release is a more useful archive for such packages (which
generally haven't changed since then).  It's on thousands of CDs,
after all, and we archive it on archive.debian.org.

Richard Braakman


Reply to: