Bug#809441: apt: provide a global resource for upgradeable packages

[Thilo Six <debian@Xk2c.de>]

Hello Julian,

Happy New Year!


>> in Debian there are several tools which calculate the number of
>> available pkgs updates and the specific data
>> <pkg> <version_old> <version_new>
>> on their own.
> 
> What does define an available package update for you? The easiest definition
> is:
> 
> (1) installed package where candidate is newer than installed version
> 
> But there is also:
> 
> (2) installed package where a newer version exists
> 
> and:
> 
> (3) installed package that can be upgraded to a newer version.

Thanks for your answer.
I am a bit overwhelmed by this question actually.

Well my personal use case for this is, is to have a "preview" of what come
around the corner when i next do "full-upgrade".
The sample script i gave has served me quite well in this regard for several
months now. It is actually modeled after:
% wajig toupgrade

Please note with my solution there is one catch though.
As "full-upgrade" can also install additional pkgs or remove them, depending on
that one of the colums <version_old> or <version_new> is empty.

If i have to choose one option from the above i would go for 3.
Expecting it would also respect pinning then?

>> This results in several tools here that all do the same thing over and over again.
>> (Update notifier e.g. apper, byobu GNU screen wrapper, to include it in status
>> line, and so on...)
>>
>> Local i have a script which does this once everytime 'update' is run.
>> I attach it.
>>
>> I would like to ask APT maintainers if you would be interested to include/create
>> such a global resource which could be easyly reused by other clients then.
> 
> We have an API. An API is there for people to use it. It's not that fast
> though, it takes about 400ms to complete for stupid reasons, unless you
> are clever -- The one below takes less than 80 ms on my system.

Well, my opinion here is, also a precompiled file with all the information
needed is also an API.
In the end personally i do not care much about how this API is technical
realised, as long it provides the needed features and that includes speed.
The below code (which i simply do not understand as i do not speak C) probably
is nice, but is difficult to reuse in shell scripts (on its own).
And shell is my #1 tool in this regard.

The idea was to have one simple resource which could straight forward and fast
be used to inform about upcoming updates, e.g. here is the list, formate it to
your will and be done.
Instead of recompiling this list in the first place over and over again, which is:
a) very expensive
b) therefore is quite difficult to handle (even file locking comes into play
   which is a rather challenging task to do in shell).
c) wastes time

A precomiled file with all the informations needed even has the advantage that
inotify could be used, instead of repolling the file over again.

> We need to optimise our other API the pkgDepCache, as that incurs a 400ms
> overhead or more, as its startup time is linear to the number of dependencies.

Yes, that is quite a challenge. Doing a completion in shell on all avail pkgs
without any prefix takes several seconds here (actually feels like minutes).
With prefix it is much faster (at least when prefix != 'lib'  ;)

I realise you have to take care of a lot of things to not break.
I am a bit sad to not being able to help much with the design of this.

Thanks for your answer.


kind regards,

     Thilo


> -- Source code:
> 
> #include <apt-pkg/cachefile.h>
> #include <apt-pkg/init.h>
> #include <apt-pkg/version.h>
> #include <iostream>
> 
> int main(void)
> {
>     struct error_dump {
>         ~error_dump() {
>             _error->DumpErrors();
>         }
>     } dumper;
>     pkgInitConfig(*_config);
>     pkgInitSystem(*_config, _system);
> 
>     pkgCacheFile file;
> 
>     pkgCache *cache = file.GetPkgCache();
>     pkgPolicy *policy = file.GetPolicy();
>     int count = 0;
>     if (cache == nullptr || policy == nullptr)
>         return 1;
> 
>     for (auto P = cache->PkgBegin(); !P.end(); ++P) {
>         auto I = P.CurrentVer();
>         if (I.end())
>             continue;
> 
>         auto C =policy->GetCandidateVer(P);
>         if (C.end())
>             continue;
>         if (_system->VS->CmpVersion(C.VerStr(), I.VerStr()) > 0)
>             count++;
>     }
> 
>     std::cerr << count << std::endl;
>     return 0;
> }