Bug#804253: apt-listbugs: Please allow pinning broken version to -1
On Fri, 11 Dec 2015 23:56:03 +0100 Julian Andres Klode wrote:
> On Fri, Dec 11, 2015 at 11:38:49PM +0100, Francesco Poli wrote:
> > So, please, in case you are still convinced that there's something that
> > could/should be improved in apt-listbugs, clearly describe:
> > • the behavior you experienced
> > • what's wrong with it
> > • what you expected apt-listbugs to do instead
> >
> >
>
> It's really simple, I'll try to explain it *precisely*:
>
> If there is a new package version uploaded, I immediately want to
> know if it fixed the bug when there is a new version available.
What you really seem to want is a post-update hook in APT that
automatically invokes /etc/cron.daily/apt-listbugs after each run of
# apt update
I am not sure: is APT::Update::Post-Invoke-Success such a hook?
If this is the case, then please try adding something like
APT::Update::Post-Invoke-Success {"/etc/cron.daily/apt-listbugs";};
to your APT configuration and tell me whether it does what you wish.
By the way, where is APT::Update::Post-Invoke-Success documented?
I failed to find any clear description in the apt.conf(5) man page...
Please let me know.
--
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
pgp1fA5ftKAIm.pgp
Description: PGP signature
Bug#804253: apt-listbugs: Please allow pinning broken version to -1
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
Bug#804253: apt-listbugs: Please allow pinning broken version to -1
On Fri, 11 Dec 2015 13:18:43 +0100 Julian Andres Klode wrote: > On Fri, Nov 06, 2015 at 07:46:19PM +0100, Francesco Poli wrote: [...] > > 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. Sorry, but I am not sure I understand what you mean. If a package is pinned to its currently installed version (by apt-listbugs or manually or otherwise), I think it should be no surprise that its upgrade is blocked. It may also happen that the same pin prevents other packages from being upgraded (for instance, when those other package upgrades would introduce a dependency on the new version of the pinned package). Hence, I consider what you describe as a perfectly normal situation: you pinned a package in order to avoid a bug, and that package is not upgraded (until the bug is fixed). This may also prevent some other package upgrades. If you manually remove the pin, the upgrade is performed. That means that you prefer living with the bug (even before it's fixed), rather than living with the old version of the package. It's up to you to decide, but I don't see anything mysterious in all this... > > 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. What do you mean? If you mean that you do not get the upgrade until the next day, well I think this is normal: the daily cron job is indeed run daily and you have to wait one day (at most) in order to see its effects... This may even be an advantage in some cases where the bug is promptly reopened, because it was not fixed properly. On the other hand, if you mean that you never get the upgrade, I wonder how that can happen. The cron job checks whether the bug is fixed in the candidate version (that is to say: the version of the package that would get installed, if the pin were removed). If the candidate version is considered as fixed because it's newer than the version that closes the bug, then the pin is removed, even if the candidate version is not *exactly* the one that closes the bug. If you have a specific example of this second scenario, I would be interested in looking into it. > > > > 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. I am really sorry, but I am having a hard time while trying to understand your needs. It's not clear to me what's the scenario you are referring to, what's wrong with it, and what is the behavior you would prefer. When this is clear, we will be able to start thinking about possible changes in apt-listbugs (if at all needed and reasonable). Not before. So, please, in case you are still convinced that there's something that could/should be improved in apt-listbugs, clearly describe: • the behavior you experienced • what's wrong with it • what you expected apt-listbugs to do instead -- 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 pgpIKyCTNkCUC.pgp Description: PGP signature
Bug#804253: apt-listbugs: Please allow pinning broken version to -1
On Fri, Dec 11, 2015 at 11:38:49PM +0100, Francesco Poli wrote: > So, please, in case you are still convinced that there's something that > could/should be improved in apt-listbugs, clearly describe: > • the behavior you experienced > • what's wrong with it > • what you expected apt-listbugs to do instead > > It's really simple, I'll try to explain it *precisely*: If there is a new package version uploaded, I immediately want to know if it fixed the bug when there is a new version available. -- 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
Bug#804253: apt-listbugs: Please allow pinning broken version to -1
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
Bug#804253: apt-listbugs: Please allow pinning broken version to -1
Package: apt-listbugs Version: 0.1.17 Severity: wishlist 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. This won't work for APT < 1.1, so this should be an optional configuration option. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (100, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-listbugs depends on: ii apt 1.1~exp14 ii ruby1:2.1.5.1 ii ruby-debian 0.3.9+b2 ii ruby-gettext3.1.7-1 ii ruby-soap4r 2.0.5-3 ii ruby-unicode0.4.4-2+b4 ii ruby-xmlparser 0.7.3-1+b1 ii ruby2.1 [ruby-interpreter] 2.1.5-4 Versions of packages apt-listbugs recommends: ii ruby-httpclient 2.3.3-3.1 Versions of packages apt-listbugs suggests: ii debianutils 4.5.1 ii google-chrome-stable [www-browser] 46.0.2490.80-1 ii links2 [www-browser]2.12-1 ii lynx-cur [www-browser] 2.8.9dev6-4 ii netsurf [www-browser] 3.2+dfsg-2.2 ii netsurf-gtk [www-browser] 3.2+dfsg-2.2 ii reportbug 6.6.5 ii w3m [www-browser] 0.5.3-25 -- no debconf information -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you.
