On Sat, 12 Apr 2008 16:27:28 +0200 Francesco Poli wrote: [...] > IIUC, aptcleanup parses /etc/apt/preferences and creates a list of > pinned packages. > Then aptcleanup queries the BTS (by invoking apt-listbugs on the list of > pinned packages) in order to see whether the currently pinned packages > have RC bugs. Finally, aptcleanup compares the list of currently pinned > packages with the list of RC-buggy pinned packages and spits out a new > preferences file which only pins RC-buggy packages.
Again assuming that the above is correct, I don't think that this logic
is appropriate for aptcleanup. That is to say, I don't think that
waiting for the pinned package to be non-RC-buggy before unpinning it
is the right thing to do.
The reason is: when I ask apt-listbugs to pin a package for me, I do so
because the new version that would otherwise be installed is affected
by some bugs that I think would have an unacceptable impact on my
system. From now on, I will call these bugs "the bugs that I fear".
The bugs that I fear are automatically annotated by apt-listbugs
in /etc/apt/preferences in Explanation: fields.
When the bugs that I fear "go away" (either because they have been
downgraded below the RC threshold, or because they have been fixed in a
newly available version of the package, or because they have been
reassigned to another package), the previously pinned package should be
unpinned, *even if* there are other new RC-bugs that affect the newly
available version.
If there are no other RC-bugs that affect the newly available version
of the package, the package will be upgraded during the next "aptitude
safe-upgrade" run.
On the other hand, if there are other RC-bugs, the package will be
ready to be upgraded during the next "aptitude safe-upgrade" run and
apt-listbugs will kick in alerting the user about the new RC-bugs: the
user will examine those new RC-bugs and decide whether to pin the
package again or else let the upgrade happen.
This seems the right behavior to me.
aptcleanup should only care about the bugs that I fear, when deciding
whether to unpin a package.
How can this be achieved?
I think the design of aptcleanup could be changed as follows.
0) parse /etc/apt/preferences, reading pinned packages and the bugs
that explain their pinning ("bugs that the user fear")
1) for each pinned package
1.1) determine the unpinned_candidate_version (that is to say, the
version that would be installed if the pinning were removed)
1.2) for each bug that the user fears
1.2.1) query the BTS about the bug and find out whether the bug
is still present *and* still RC in the
unpinned_candidate_version
1.3) if all the bugs that the user fears went away, then the package
should be unpinned, hence do not include it in the list of buggy
packages
1.4) if on the other hand some bugs that the user fears haven't yet
gone away, then the package should stay pinned, hence include
it in the list of buggy packages
2) compare the list of pinned packages with the list of buggy packages
and spit out a new preferences file which only pins buggy packages
How do I determine the unpinned_candidate_version of PACKAGE?
Something like the following, I would say:
$ apt-cache -o Dir::Etc::Preferences=/dev/null policy PACKAGE | awk
'/Candidate:/ { print $2; }'
Well, what do you think about my proposed redesign of aptcleanup?
Is it reasonable?
Is it feasible?
Or am I missing something important?
Thanks for maintaining apt-listbugs and thanks for reading thus
far! ;-)
--
http://frx.netsons.org/progs/scripts/refresh-pubring.html
New! Version 0.6 available! What? See for yourself!
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpE5re8c4Z9F.pgp
Description: PGP signature
