Releasing kapture 0.2
After an intensive hacking week, i think it’s time to get this out of the door. It was long overdue already. The good thing is, that after disabling the experimental package selection/installation method, things are getting quite usable. I just made it optional in the code for now, disabled by the client. I guess one day i’ll make it an user option, but i need to wrap my head around some configuration interface first (hmm, kconfig would be nice, but i need some more general, libcapture-driven config interface. So it’s probably going to be pkgTagFile derived, something along the lines of _config object from libapt-pkg.
On the other front, the grouper concept seems to work rather nicely. For those, who don’t know kapture (most of you, i suppose), it is a mechanizm turning the flat package cache into all the nice trees you will find in kapture. It’s not done the synaptic way (which is, let’s admit it, pretty simple, but also quite limited: they use one class, that has an enum in it, and according to value of some parameter, it can produce various predefined trees). The libcapture concept is quite different; it has quite a bit common with the aptitude implementation, where i seen it and liked it on the first sight. It consists of creating a rather arbitrary “chain” of various groupers. These goupers then sort their input into categories, or discard them or just pass along. The nice effect of this can be seen for example with the “Changes View” in the new kapture: it is the exactly same code that the neighbouring Package Tree, just a different grouper chain was passed to the constructor.
I am right now contemplating on stretching the grouper concept even bit further. Right now, TreeNodes are produced by a specialized class, called Feeder (which is an instance of NodeProducer). The tree serves as a consumer, passing the created nodes to the grouper chain. What i’d like to achieve is that there is no NodeProducer, but rather the first grouper in the chain will produce all the nodes for further processing. This needs some forethought with regards to Depends view and such. But i guess this is feasible.
The biggest yet untouched problem in kapture is libapt-pkg — dpkg interface. It quite a bit sucks, as the libapt-pkg makes assumption (pretty bad one), that it’s running in a terminal. What i want to achieve, is to create a konsole part and redirect I/O there. Not only that, but also get the output from dpkg —status-fd into kapture and make some progress info out of it. The terminal is still needed though, as some of the packages’ maintainer scripts rely on it. So i will have to wrap my head around some fd redirection, some IPC and/or threading and think something out. Any ideas? ;)
Oh, for those interested, kapture is available in the kalyxo archive.