On Fri, Nov 06, 2015 at 07:46:19PM +0100, Francesco Poli wrote: > 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!
Sorry it took so long to reply, but here we go: > 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. What happens currently for me is that some packages are not upgraded and I wonder why - I then manually remove the apt-listbugs pin and run apt (full-)upgrade again. Another problem with a daily cron job is the following: If the bug was fixed between two dak runs on the same day, I'll not get the new upgrade, because the cron job has not run yet. That happens often enough. > 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. Optimally we would have hooks in APT that allow you to just block a single upgrade and let the rest go on, but without that feature, I think the best that can be done for my use case is the -1 pinning thing. > 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. You can just clean up with the cron job. Or clean up with a post install hook, that just checks if a newer version of the blocked packages was installed. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.
signature.asc
Description: PGP signature
