Week 1: exp5, disappear and beyond
On Tuesday Michael had the pleasure to upload 0.7.26~exp5 to the real archive… ähm I mean to the official debian experimental archive. 😉
This upload fixes mostly smaller things nobody cared to write a bug report about, so I successfully missed my personal goal in my unofficial ABW (APT bugs of the week, see RCBW), but I guess I have just not found the bug report for the bugs I fixed yet. At least I have a lot to choose from: 654 bugs currently against APT. At least 654 to many 😉 And let us assume ABW would work out and seven open bugs would disappear each week: We will have a bugfree APT in ~2 years 😄
Disappear is the right catchword here for the biggest change. Not code wise, but logic wise. dpkg supports it to let packages automatically disappear from the system if they have no files left (and nothing depends on them). Unfortunately this means to things: 1. An APT version which doesn't know that will maybe unpack the soon-to-be-disappeared package, dpkg let it disappear and APT later tries to configure it -> BANG! Noninstalled packages can't be configured. 2. APT - and even dpkg - doesn't know beforehand which packages will disappear, so APT can't show them before the actions. Bad as you normally say: APT does nothing more than executing the things you instructed it to do. If suddenly packages are not longer installed after an APT call what will the user think?
Fortunately we can at least enhance the situation for both points. The first is relatively trivial by saving the packages dpkg let disappear and just check before configuring packages if they haven't disappeared yet. The second is a compromise: APT can't display it beforehand, but it is an automatic action the user doesn't need to worry about anyway as the user will not miss functionality - and this is the concern the user has then a package is no longer installed. libapt-pkg therefore exports the packages dpkg had let disappear to the front-end for consumption and apt-get choses to display a friendly message at the end of its run to the user:
The following packages disappeared from your system as all files have been overwritten by other packages: apt dpkg Note: This is done automatic and on purpose by dpkg. I think so far this is the best we can do in this situation.
After ~exp5 I worked a bit further on the disappeared thing and now it should not only be logged also to history.log but also transfers the manual-installed bit from the disappeared package to the package(s) replacing it to enhance the experience in package renames: The new package would be automatic installed and after the disappear of the old it will be tagged for autoremove otherwise. For the full action plan refer to the end of this mail.
The rest of the week was used to not understand the ADA people and to implement a new helperclass around std::set in the form that std::set::const_iterator smells exactly like a pkgCache::PkgIterator so it is easier to change between iterating over the complete cache vs. iteration only over a subset of the cache. For the future it is might be an interesting exercise to implement APT::PackageSet with std::set instead, but for now it is easier this way. But a class APT::PackageSet alone isn't too interesting, more interesting is how it can help us: For this it currently has two static methods FromRegEx and FromCommandLine which basically are factored out code from the apt-* commands. Using them has the lovely effect that (nearly) all commands in apt-cache now accept also regex as package names. Cool so far, isn't it? My current plan is to add another more capable FromCommandLine which can handle the various modifiers apt-get has for its install commands which in exchange results in a more uniform interface to the tools - and nearly more important: I can close a bunch of bugs 😉
You might ask now what this all has to do with MultiArch - the last thing is relatively important for it: The user needs a way to express which package (from which architecture) (s)he wants to have installed/removed/whatever and if you don't want to write the same multiple times you better add a layer of abstraction. 😉 Beside that I fixed a few minor things for MultiArch this week and experimented a bit with the moveable MMap but this is to minor so far to highlight it in a blog post, as I have already written too much… so see you next week - or earlier maybe. 🙂