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
