Re: Upcoming Section changes in the archive (deborphan)
On Sun, Mar 01, 2009 at 10:14:34AM +0100, Bernhard R. Link wrote:
> * Carsten Hey <c.hey@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.
Yes, exactly. What will be in the deprecated section is not that
important since deborphan can be accordingly adapted and until this is
done no package from this section is detected as orphan per default.
> There have been non-library packages in oldlibs, for example
> shellutils and other transitional packages.
Transitional or dummy packages that are removed will not cause a RC bug
but they are no libraries and thus actually do not belong to oldlibs.
There is as far as I know no official description of what packages
belong to which section so we should use the obvious definition implied
by the name of the sections.
> For those deborphans behaviour of removing the package once no longer
> something depends on them was exactly the right thing.
In case of fileutils, textutils and shellutils one justification to move
them to oldlibs was that deborphan would list them by default, this may
be appropriate in carefully selected cases.
> Thus I think the issue are not non-library packages, but packages that
> supply user-visible functionality.
There is no issue at all unless packages which should not be listed are
(temporary) moved to oldlibs, which nobody planned. Enrico only
suggested to put them directly to deprecated and then move the packages
from oldlibs to deprecated, which would be ok.
I only did mention what would happen if this is done in an other
sequence to ensure that everybody involved in the upcoming section
changes is aware of this possible serious consequences.
> 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.
With these requirements deprecated could really be handled like oldlibs
but until now I did not have the impression that this is planned. This
would also imply that no old, rarely used and unsupported mail user
agent or web server could be part of deprecated at any time, actually no
package including a file in {/usr,}/{s,}bin.
Regards
Carsten
Reply to: