PackageKit tries really hard to work for these people. PackageKit is designed for these people.
Debconf is a simple protocol that dpkg uses to ask the user configuration data at install time. I think it’s generally a bad idea, as installing should generally be silent and automatic and configuration should be a separate step. That said, PackageKit needs to also work on Debian, as some people seem to really like debconf and are not happy shipping a PackageKit that won’t talk the debconf protocol.
So, last weekend I sat down and wrote the required PackageKit-glib2 patches to make the PackageKit-enabled frontends setup a pipe for use in apt, and to spawn debconf when required. Of course, this is a no-op for things like searching and when a package needs no configuration, but for other packages it blocks (urgh) the transaction and the user gets asked questions. Of course, if the transaction is running non-interactively, then the backend won’t ask any questions at all.
Of course, I’m kinda disappointed someone from Debian didn’t write the patch themselves; with all the blogs, wiki articles and emails about the “lack of debconf support in PackageKit” it would have been less typing to actually write the patch. Hey ho, it’s done now. If you install the recently released 0.6.10, then it “just works” with no re-compiles of any front-end clients required.
Of course, I should also like to thank Daniel Nicoletti and Sebastian Heinlein for development help, and Matthias Klumpp for testing. Thanks.
FWIW, we are going to rely on SessionInstaller which implements the PackageKit session services on top of aptd, instead of using the reference implementation.
That’s nice. I thought PackageKit already had debconf support and nobody cared about it; seems I was wrong. As Np237 already write, we use an alternative implementation of the PackageKit session service in Debian now. This alternative is called sessioninstaller, is written in Python, and developed by Sebastian Heinlein, and the package maintained by me.
While I’m not happy about the state of our own solution (which has some bugs only occuring due to it’s dynamic language) and PackageKit will come to Debian soon (http://bugs.debian.org/468132), I don’t see any way Debian would include PackageKit by default in the near future – we currently ship the same package management tools as Ubuntu does (such as Software Center, Synaptic, Update Manager, and others) and diverging from Ubuntu here is not helpful.
I will do my best to ensure that both sessioninstaller and PackageKit can co-exist peacefully in Debian and that packages making use of the session service can work with either one.
I should probably add that although I maintain the sessioninstaller and aptdaemon packages (and more upper and lower levels written in Python), I generally prefer implementations that are written in documented C, like PackageKit.
BTW, it would be nice if you go with the hype and replace OpenOffice with LibreOffice on http://packagekit.org/pk-profiles.html – and Latex => LaTeX would be nice too.
Wow, I’m really glad to hear this! I was worried that we would get a fight between PackageKit and SessionInstaller people in Debian. (Which would be absolutely useless) Co-existence looks like the right way, so we can use the solution which performs best and matches all requirements, be it SI or PK.
“but for other packages it blocks (urgh) the transaction and the user gets asked questions.”
The update-manager in Ubuntu has a queue for these questions, so that the transaction won’t be blocked. I don’t know, if Synaptic does it too, but I see no reason, why Packagekit should block the transaction.