[I am resending this a second time, since the first attempt bounced from the bug address... Sorry for the extra message, Vincent]
On Mon, 17 Jun 2013 02:02:09 +0200 Vincent Lefevre wrote: > On 2013-06-16 23:21:19 +0200, Francesco Poli wrote: > > I can confirm that there's no form of caching (at least, nothing > > explicitly implemented in the program; I am not 100 % sure about the > > ruby SOAP client library, but I think it does not cache queries > > transparently...): apt-listbugs needs the most up-to-date information > > known to the BTS, therefore it queries the BTS SOAP interface each time. > > This is a silly argument! Sorry, I failed to express myself clearly. It would indeed be a silly reasoning, if it were intended to mean that *any* form of caching should be considered harmful™ for apt-listbugs. This was not what I meant, although I admit that it could look like it were... :-( Please let me try again: → apt-listbugs needs up-to-date (or *almost* up-to-date) information about bugs → information from hours or days before is outdated and should not be relied upon → the most common use-case for apt-listbugs is: one invocation followed by another one done a while later and probably for a different set of packages to be checked for bugs I guess that this is the reason why nobody has implemented a cache for the SOAP queries done by apt-listbugs. I think that this tool was probably not designed thinking about two invocations in a row. Please take into account that I am just guessing here, since I adopted the package well after its initial design and implementation. > After a few *seconds* (which happens all > the time if the recommended way to do a OR is to call apt-listbugs > several times), Make no mistake: invoking apt-listbugs multiple times in a row is not the "recommended" way to join filters in OR with each other. It's just a strategy I thought of, when someone (you!) asked *for the first time* how to set up more expressive filter operations. > one can assume that cache information is up-to-date. > There's nothing wrong in having a cache if the expire time is low > (e.g. 5 minutes). Sure there's nothing wrong. But I guess that nobody implemented that, since common use-cases suggested it was not worth the effort... I hope I clarified what I meant. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpvTXXAp9YKQ.pgp
Description: PGP signature
