* Carsten Hey <c....@web.de> [090228 19:21]:
> > It shouldn't be anything harder than adding 'deprecated'
> > (non-library, deprecated software) to complement oldlibs,
>
> Adding non-library packages to oldlibs would cause these to be handled
> like a library by deborphan and thus possibly being falsely displayed as
> orphaned libraries. Since people tend to run aptitude purge `deborphan`
> in loops [1] or use similar constructs I saw in the past this would lead
> to unintended package removals.
I think the "unintended package removal" depends mostly on what is
actually put in oldlibs or a new deprecated section.
There have been non-library packages in oldlibs, for example shellutils
and other transitional packages. For those deborphans behaviour of
removing the package once no longer something depends on them was
exactly the right thing.
Thus I think the issue are not non-library packages, but packages that
supply user-visible functionality. If the new deprecated section would
have the requirement that packages to be put there should not cause
significant[1] user visible changes, then everything would be ok.
Hochachtungsvoll,
Bernhard R. Link
[1] Of course defining "significant" is the problem here. As one can
have user-compiled programs dynamically linked against old libraries,
asking for only empty transition packages makes no sense.
I'd for example argue that a deprecated/transitional package just offering
a wrapper for the new program whould be equally allowed to be removed in
this way once there are no more package dependencies...
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
