Re: [PROPOSAL] Archive audit, cruft removal, unmaintained packages
On Wed, Aug 18, 1999 at 06:41:17AM +0200, Richard Braakman wrote:
> 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.
It seems to be to be less work. If some one else takes the time to atleast
come up with a list of cruft that needs to be removed and takes the time
to research each one and determine the course in which to remove it, then
all you have to do is "rm -f cruft_file" (and update the archive database
of course).
> 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.
Then this information needs to be addressed more publically. All of the
maintainers need to be made more aware of the state of the archive and how
their actions affect it. Right now most just upload and assume all will
be taken care of.
> 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.
That's a good start, but it's nothing more than rhetoric if we don't have
a clear policy on the repercussions for not following this (ie.
"irresponsibility in regards to library upgrades that break or seriously
hurt the distribution will result in the library package being removed
from your maintainership", yes it's harsh).
> > 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.
They have been floating around for more than a little while, and people
seem to regard it as unfair. I think these people need to get a grip and
decide just how important Debian is as a whole, ie. some order needs to be
instilled before our acceptible "chaos level" get's too unmanageable.
> > 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.
Agreed. Most likely record keeping will have to start from the beggining
of the fork. Then at freeze, schedule known obsolete packages for removal
and determine how to resolve any issues in removing them. At deep freeze,
the packages go.
Ben
Reply to: