Comment 13 for bug 830492

> Great to hear that you work on a more general fix for apt-get.

As described in comment #5, I was originally planning to make a virtual package server such that a list of files can be easily obtained from any package manager just by directing it to the server. It would then download them and place in /var/cache/apt/archives/, then you would try again in the package manager which would have nothing to download. I was going to wrap apt-get such that the retry is automatic. Then I noticed that instead of wrapping apt-get, there are some Python APT bindings available. And I was about to start reinventing parts of Aptdaemon.

So instead of using apt-get, I will use aptdcon and implement solutions in Aptdaemon as described in comment #7.

After I have done this, I may still apply the virtual package server idea as an Aptdaemon client. This may allow 'legacy' package managers like Synaptic to /partially/ use Aptdaemon and allow concurrent downloads/installs. Synaptic, however, will still require bug #80753 to be fixed in this case.

> Download and install in parallel is currently progressing only slowly, during the current summer of code we got a new order algorithm that can now order the packages in a way that puts them together in groups that can be installed independently.

That's interesting. Are those groups equivalent to transactions?

> You linksed to "pacserve" which is quite interessting. Are you aware of the similar (but not quite the same) project "squid-deb-proxy" and "squid-deb-proxy-client" ?

No, I hadn't. My long-term aim is that more efficient downloads (from LAN if available) can be achieved without configuring or messing around with proxies/shared caches/local mirrors/etc.

So I'm preferring to contribute to Aptdaemon. It would be awesome if Ubuntu has these Aptdaemon solutions out-of-the-box. I'm also thinking that this is going to take a great deal of load off Ubuntu's servers if/when this happens.