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

[Adam Di Carlo <adam@onshore.com>]

[Old topic, I know, but it's important]

IMHO, the best possible way to both eliminate cruft and also remove
burden on the archive maintainers is to allow the registered developer
to remove their own packages.  However, this would involve some
dpkg-dev development of some sort -- probably so that you could upload
special .changes files with delete instructions for a package (and
binary packages), and then modify dinstall to process that (removing
for all port while we're at it).

If someone were to go through and look for cruft, I think they should
identify some likely packages -- not just packages that have been
renamed, but also stuff which is truly obsolete, such as mh (a better
and well-maintained replacement exists).  These cases are much more
discretionary.  Cruft-finders should ask upstream maintainers what
their thoughts are.

Another way to look for cruft would be to just try to find binary
packages in main that we can't find source for?

Richard Braakman <dark@xs4all.nl> writes:
> Library changes, as well as other kinds of package renaming, must have
> a description of the transition strategy (or a reference to such a
> description) in their changelog.  In some cases, this can be as simple
> as "Nothing depends on the old package so please remove it".  In others,
> it can be very complex indeed (such as the libc5 -> libc6 transition).
> 
> If there is no transition strategy, the archive managers will reject the
> package.  [This is the major change; the status quo is that we try to
> guess at a good strategy, or just ignore the problem].
> 
> This makes the transition clearly the package maintainer's responsibility.
> It is unfortunate that rejecting a package is the only way we can
> communicate about the package.  Maybe we should design some kind of 
> holding area.  (Incoming/REJECT does hold a package for two weeks, though.)
> 
> This information should probably go into the Developer's Reference.

Assuming you really mean "must" here, then you mean the Policy
document or even the Packaging Manual.  The Devel Ref carries no
weight of policy.

I think we really *should* suggest that new or unexperierced
maintainers not maintain shared library packages.  I don't know how we
could possibly could enforce that .


--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>