FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-28-2009, 05:21 PM
Carsten Hey
 
Default Upcoming Section changes in the archive (deborphan)

On Sat, Feb 28, 2009 at 01:03:39PM +0100, Enrico Zini wrote:
> On Fri, Feb 27, 2009 at 10:03:55PM -0800, Steve Langasek wrote:
> > There are tools that understand the special meaning of the 'oldlibs'
> > section and treat it specially; at least deborphan comes to mind,
> > there may be others. I don't see the necessity for such a section
> > rename,

Actually he also talks about adding deprecated non-library packages, so
this is more than just a "section rename".

> > but if it happens I think it needs to be announced in advance and
> > coordinated.

Per default deborphan assumes that libraries are in libs or oldlibs.
This is necessary to find orphaned libraries but prevent packages like
libpam* or libapache* to be displayed as orphans. The upcoming section
changes will break this assumption and thus there will be many false
negatives (orphaned libraries that are not found anymore) until large
parts of deborphan have been adapted or rewritten.

In comparison to the other proposed changes the removal of oldlibs is
only a minor issue for deborphan. With my deborphan upstream/maintainer
hat on: Given that no non-library packages will be added to oldlibs,
and this change happens at the same time as the other section changes,
the removal of oldlibs is ok for me and I do not feel the need to
further coordinate this. Additionally no non-library packages must be
added to libs or libdevel at any time, I guess nobody had such plans
anyway.

> 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.

> ask tools to treat them equally,

The two sections are not exactly equal and handling them equal would be
wrong (see above).

> and when we're satisfied that they do, just get rid of oldlibs.

No, deborphan will be adapted after all section related changes in the
archive are done. Ad interim, conservative defaults and algorithms in
deborphan ensure that additional or missing sections do not cause false
positives.

Deborphan will support both section layouts until the next change
related to sections happens, at least unless the new section layout will
be messed up in a, from the viewpoint of deborphan, non-backwards
compatible way.


Regards
Carsten

[1] http://debaday.debian.net/2007/10/21/deborphan-find-packages-you-dont-want/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 08:14 AM
"Bernhard R. Link"
 
Default Upcoming Section changes in the archive (deborphan)

* 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.

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 10:31 AM
Carsten Hey
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 11:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org