Re: Bug#758234: it's actively harmful
On Wed, Oct 29, 2014 at 01:30:55PM +0000, Simon McVittie wrote:
> On 29/10/14 12:41, Santiago Vila wrote:
> > If we are going to take that route, we might just make all libraries
> > optional as a general rule.
>
> That seems reasonable to me, with the possible exception of the few
> libraries that could justify their own priority via the "wtf, why isn't
> this installed?" rule of thumb, like libc6.
Actually, we don't need a rule like that for libc6, because lots of
essential packages depend on it.
We would only need to say "wtf, why isn't this installed?" for a
library that works like a plugin (i.e. a library on which no other
packages depend).
> >> [footnote: This ensures that a
> >> # high-priority package transitioning to a new library dependency
> >> # does not result in both the old and new libraries being installed
> >> # on new systems, due to the old library's priority remaining high.]
> >
> > However, I don't like the wording of the footnote.
> >
> > Why would the old library's priority remain high to begin with?
>
> To have a concrete example to talk about, let's say cron (Priority:
> important) moves from using libstuff0 to using libstuff1.
>
> If libstuff0 and libstuff1 both come from a "libstuff" source package,
> but you have more than one apt source - e.g. stable on a mostly testing
> system - then your apt can still see the older libstuff0 binaries, with
> the "important" priority that was appropriate when cron/stable depended
> on them. I believe this means it won't automatically get rid of libstuff0?
I think we don't even need to consider more than one apt source to see
the problem.
We could just imagine the case where a user changes "stable" to
"testing" everywhere in sources.list and then upgrades to testing.
Whatever solution to the problem of "getting rid of unused libraries"
in this simplified case would probably be a solution for the case of
mixed apt sources as well.
> If libstuff0 and libstuff1 are in parallel stuff0, stuff1 source
> packages (like Gtk2 and Gtk3), it is not clear to me how the ftp team
> should be expected to know that libstuff0 should be demoted from
> important to optional, or when would be the correct time to do so.
A good rule to follow if we keep current policy would be that
libraries should always have the lowest priority possible
(but >= optional) that makes the rule
"packages should not depend on others with lower priority values"
to be true.
The rule would be, of course, applied independently for each
distribution (stable, testing, unstable).
I believe there would be plenty of room for automation here.
> It could equally well be a core package transitioning from one
> command-line tool to another (dpkg moving from lzma to xz), or from
> command-line tool to library (dpkg's tar.xz support again), or changing
> its implementation to not need one of its old dependencies (systemd used
> to require libdbus-1-3, but has switched to its own D-Bus implementation).
I agree that there may be a lot of different cases, but many, if not
most of them should probably be automated.
> > It sounds as "Lack of manpower in the FTP team forced us to change the
> > rules about package priorities, since they did not change priorities
> > often enough".
>
> Is your intention that the maintainer of libstuff would track the
> transition and buildd status, somehow work out when libstuff0 no longer
> qualified for important priority, and file ftp.debian.org bugs to demote
> it?
AFAIK, that's what we are already doing, except that it's not always
the maintainer of libstuff the one who tracks the priorities to be
changed and submit the bugs.
> Or that the ftp team determine (in some hopefully automated way)
> that libstuff0 no longer qualifies for important, and demote it? Or what?
I think some automation on this issue would benefit everybody, yes, at
least while we keep the current rules regarding priorities.
My point is that there may be legitimate and valid reasons to change
the rules about priorities, but "we didn't automate enough" should not
be one of them.
Thanks.
Reply to: