Control: clone -1 release-notes Control: severity -1 wishlist Hi!
The bug against dpkg, is about a behavior change that many sysadmins might be surprised to find, so to avoid that it might make sense to document in as many places as possible. Hmm, but I guess it might be too late for this now, and going through the release notes, I'm not sure if this really fits in there. I was not sure where to plug such information there anyway... On Sun, 2013-04-21 at 19:30:48 +0200, Guillem Jover wrote: > Regarding this bug report. Yes, the missing documentation is a bug, > and was an oversight at the time, my bad. This behavior change was not > done out of a whim, as seems to be implied in several of the mails on > this bug report, there was a reason as I explained at the time, dpkg > would otherwise be unable to refer to packages on its own database; > the fact that I consider the new behavior the correct one is just an > extra, and in addition a useful warning is printed on unknown packages > which could be missed previously (even with an up-to-date available > database). ... I'm attaching a small tentative patch, on the best place I could find, just in case. Thanks, Guillem
Index: en/upgrading.dbk =================================================================== --- en/upgrading.dbk (revision 10039) +++ en/upgrading.dbk (working copy) @@ -368,7 +368,10 @@ </screen> <para> Replace <literal>hold</literal> with <literal>install</literal> to unset the -<quote>hold</quote> state. +<quote>hold</quote> state. Also take into account that starting with dpkg +1.16.x, an up-to-date available database is needed for the command to be +useful (see the <ulink url="&url-wiki;Teams/Dpkg/FAQ">dpkg FAQ</ulink> +for more information). </para> <para> If there is anything you need to fix, it is best to make sure your