Control: tags -1 moreinfo
On Fri, 6 Nov 2015 16:36:01 +0100 Julian Andres Klode wrote: > Package: apt-listbugs > Version: 0.1.17 > Severity: wishlist Hello Julian, thanks for your feature request! > > With APT from experimental having a new policy engine that > actually works for negative pin values, it seems like a better > idea to allow pinning the broken version to -1. > > This would mean that once a new version is available, > apt-listbugs would automatically check if that version > fixed the issue, and upgrades to the package would not > be blocked. Mmmmh, I am not too convinced that this would be an actual improvement. Please let me clarify what I mean. With the current apt-listbugs, a package may be pinned at the installed version in case its upgrade is able to introduce a bug (of worrisome severity) into the user's system. A daily cron job checks whether the bug is fixed in the package version that would be installed if the pin were removed: if this is the case, the pin is actually removed; otherwise the pin is left untouched. With your proposed new strategy, the package would be pinned so that one buggy version would be forbidden. Then, for *each* new version of the package that becomes available with the bug unfixed, apt-listbugs would prompt again the user and ask again whether the new buggy version should be forbidden. Until a fixed version becomes finally available. I have seen a good number of cases where a bug (even an RC bug) stays unfixed for several uploads, unfortunately. I think that prompting the user again and again for a previously examined bug would be annoying. It's true that I could implement a check inside apt-listbugs in order to avoid prompting again the user for already examined bugs: apt-listbugs should check whether the bug is already mentioned in one of the pins... It's probably feasible, but then I don't see any special advantage over the current implementation. Another drawback is that a number of obsolete pins would be left in APT preferences, once the bug is actually fixed and the fixed version of the package finally lands on the user's system. Unless a daily cron job does the cleaning, of course. But then, again, I don't see any special advantage over the current implementation. Maybe I am misunderstanding your idea. Please do not hesitate to elaborate a bit more, if this is the case. Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpeNO4NgGyD5.pgp
Description: PGP signature
