[Soc-coordination] GSoC - Apt Ordering - Report 4

[Christopher Baines]

Hello,

So I was talking to Michael on irc and he suggested working on allowing
apt to stop between dpkg calls. So for the user you would call apt-get
dist-upgrade, realise you have made a mistake and you actually don’t
want to upgrade a package, you can press ctrl-c and as long as you do so
soon enough, apt will stop at a safe place (no packages left
unconfigured) and exit. 

Now I realised quite quickly that this was quite hard to implement if it
needed to work when not performing Immediate Configuration on all
packages, this is for two reasons. Firstly when not using
Immediate-Configure-All, most packages are all unpacked, then all
configured, so if interrupted, apt needs to workout what operations are
needed to get the system to a safe state. But because the package
management code runs through the cache and works out what operations
need to be executed, in what order, then executes them, you would need
to repeat this step somehow. Thankfully I have avoided this for the
moment and am just looking at implementing this when using
Immediate-Configure-All.  

Even then when I began looking at this I realised that my current
implementation of Immediate Configuration is far from optimal, and even
dangerous when used with interrupts. This is because some packages that
are unpacked are not configured immediately. I ended up consolidating
some of the code, hopefully making it more manageable and safe.

In the coming week I hope to add some useful messages, something like:
Stopping due to user interrupt
Installed: packageA packageB
Updated: packageC
Removed: packageD
Didn’t Install: pacakgeE
Didn’t Remove: packageF 
However I am very open to ideas on formatting and information included
if anyone has any ideas?

On another point, I when testing the Immediate Configuration code in my
dist-upgrade vm. I noticed that it was slower, that reminded me of a
conversation with David back in March[2]. I will include an extract
here:
> My proposal would involve:
> - Allowing aptitude to:
>  - When installing a long list of packages, break down the list in to
> many groups of unrelated packages

Sounds easy at first, but you will need to think a lot about this as
you don't want too big as well as too small groups - beside that you
need to identify these groups (partly done already).

You properly want to make it configurable as a good groupsize will
depend
on the hardware we are operating on. My mobilephone for example has
maybe
very few diskspace so i want to have very small groups, but my server
with
access to a local mirror (with nearly instant download time) will spend
more
time forking and starting up dpkg than installing packages if the groups
are too small.

The good news: This groupsize problem could be avoided, if dpkg would
have
(again) a working --command-fd, so APT could spawn it once and
communicate
unpack/configure/remove requests over a fd eliminating the need to
frequently
start dpkg - which reads e.g. its huge info-database every time…

I will probably try and talk to both Michael and David about this.

Chris

1.
http://lists.alioth.debian.org/pipermail/soc-coordination/2011-July/001027.html | http://lists.debian.org/deity/2011/07/msg00012.html
2.
http://lists.alioth.debian.org/pipermail/soc-coordination/2011-March/000888.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20110731/85f8509e/attachment.pgp>