There’s been a lot of noise about PackageKit and debconf in the past, but not an awful lot of coding… Until now.
Daniel Nicoletti is the maintainer of KPackageKit, and a log time contributor to PackageKit. He’s also the guy behind all the recent SimulateX() methods that required quite a bit of clever coding to work properly on all backends. The simulate methods alone make PackageKit much more useful with apt (where updating a package can remove another) and now he’s dealing with the debconf problem.
I’ll not repeat what he’s planning to do as all the details are available on his blog, but it basically involves adding a DBus frontend on debconf and telling packagekitd a private connection of a helper program running in the session. This means debconf can work in the standard PackageKit “no blocking” modes when required (e.g. for an unattended update) but also ask required questions when setting things up like MySql when running interactively.
I’ve still not changed my stance on asking questions and blocking during a package install, but with this new helper program and secondary session interface, a lot of the debconf headaches can go away. I’m sure all the changes might take a few weeks to even be prototyped, but it’s nice things are going in the right direction.
This is a fantastic piece of news for PackageKit. The way you and Daniel worked together in the upstream list turned out to be really constructive and I’m glad a solution was found that can help Debian take advantage of the power and simplicity of PK.
There’s something I don’t understand.
Debian has a facility to ask all debconf questions up front: the package apt-utils has a tool apt-extracttemplates, that extracts the (localized) debconf questions from the deb packages in advance, so you can ask all of them _before you start installing them_.
Why is that not used? Is it because a PackageKit “transaction” is downloading+installing, and what I suggest would ask the questions after downloading? Would asking the questions before installation still be considered “blocking”?
No, asking questions before the transaction starts would not be blocking and is the best way of doing it in my opinion. It is what we do on Fedora with GPG signing, and SUSE does with EULAs.
yes,
the transaction is installPackages which involves downloading + installing, the blocking thing that Richard said is that if the transaction stops in the middle and waits for the user it’s blocking, with this Dbus front end it would be “half” blocking since the biggest problem is when an automatic update starts and there might be no one there to answer the questions, in that case a noninteractive frontend could be used.
Yes, there is the up-front feature, (that i don’t know much well), the thing is we would need to cancel the transaction so the user can answer the questions then start it again so it can finish them.
For sure things might get better with more eyes on it, but the DBus frontend will help this process a lot.
I have something that I don’t understand as well.
How can you design a software like PackageKit and have APT/dpkg integration be an after-thought? It’s not like there are many packaging tools out there that high up in the scale of popularity.
You can’t just design a GUI and then expect 10 years old core distribution tools to adapt to /your/ design, by doing hacks like having extra daemons and D-Bus interfaces. It just seems wrong, doesn’t it?
I didn’t leave dpkg as an afterthought, I can assure you. When doing my initial research (several weeks of work) I studied the design of apt and dpkg as well as about 8 other packaging systems.
When I did my research, and subsequent initial prototype, the conclusions I came to were that I wanted to focus on a modern task-driven user interaction, not dictated by “the way things have been for the last 10 years”. I wanted to get the UI interaction correct (for instance allowing unattended updated when the session is idle) and the security model usable (users can install signed updates from signed metadata without authentication by default) before I supported niche parts of specific backends.
In the case of debconf, I agree to some people it’s useful. It’s also been abused in the past, and allows packagers to do some quite insane things. Allowing the transaction to block waiting for input at random places breaks a lot of the UI interactions we are working towards, and would make the design, frankly, as bad as previous “slap a front end on apt” efforts.
By doing this out-of-band solution, as dantti is doing, we can still keep the core of PackageKit well designed with abstract APIs that clients to use, without forcing every application using PackageKit to keep open a vte widget and inhibiting logout and shutdown. There are lots of reasons that PackageKit can’t (and won’t) support this mode of operation, and I’ve covered the rationale many times over on the mailing list.
I also don’t think PackageKit is a “hack”, and I do believe it lets us do some cool things that have never been possible before. If you study the design of PackageKit, you’ll hopefully see it fits in the “sweet-spot” of an abstraction that can be used by ‘n’ frontends on ‘n’ backends, and allows application authors to add support for a single system that works anywhere.
If you have specific concerns, I urge you to join the PackageKit mailing list and we can discuss more there. If you’re a Debian user, I’m sure dantti would appreciate any help with the code, or a new tester. Thanks.