There are people who care for version numbers a lot. I don't, but I agreed to keep 1.2.x mostly new-feature and minor-bugfix-free for the duration of the Ubuntu deep-freeze cycle. That worked only so far as due to a minor misunderstanding about the ordering change I mentioned last week Ubuntu ended up "backporting" it into all supported versions (as they needed it to make their upgrades work) while in Debian it wasn't uploaded until after the release – so even with all the care taken we are slightly out of sync. Shit happens I guess.

On the upside, with the release out of the way I am free to break fix things again and so I spent most of the week brushing up a few feature branches I had previously created – like a more detailed display of hashsum errors –, discussing new feature- fixes – like if and how apt should react if the Release file is redirected to another mirror (it now will pick all indexes from this mirror to, but it will still contact the 'redirector' for each non-index file like debs. Further more a repository can now employ key pinning by specifying via a Signed-By entry which declares with which key(s) the next Release file can be signed.

And then there was a bug to be fixed in the M-A:same (un)screwing code in the solver caused by the wrong method used to get the candidate of the package (as all installed M-A:same packages need to have the exact same version there is no point in exploring solutions in which only some of them could be upgraded as they have different candidate versions).

Oh, and after discussion the mailinglist this week if and how/why we depend on gnupg{,2} I today commited the first step in getting right of gnupg{,2}: I demoted it to a Recommends in apt. The reason is simple: With a lot of work we made 1.1 support gnupg, gnupg2 and potentially beyond AND using only gpgv (or gpgv2) for the main execution paths – which for apt is of course the verification of Release files. So a user needs gnupg only if apt-key is somehow called – which isn't commonly done. We still moved to Recommends for the moment only through as some third-party packages like the one for chrome use apt-key unconditionally to add keys to the trusted set: Something you don't need apt-key for anymore since 2010 as you could just drop a file into the trusted.gpg.d directory instead. To have this more visible apt-key also sports a warning now if it detects to be called by a maintainerscript from a package which doesn't have a dependency on gnupg.

If you think that all this isn't really related to the GSoC project you are right. I started with some groundwork in extending and fixing the existing EDSP interfaces and planed how to extend it further to a point there EDSP and EIPP (external installation planner protocol) can share much of the same code. Not only to save myself some typing, but the problem of describing the current state is a shared problem which is currently dealt with in the least efficient way: Send all data – but beside a bunch of ideas and some very boring code were isn't much to show of for this week on this front. With a bit of groundwork done and 'unrelated' pillars out of the way next week will about generation EIPP requests… see you then!

This blog has no centralized comment section. Feel free to write a comment in your own blog, some other page or channel you are on to discuss stuff and/or contact me by mail. I am happy to add pointers and updates as needed.