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
Attachment:
signature.asc
Description: This is a digitally signed message part