PackageKit and debconf (progress)

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.

6 responses to “PackageKit and debconf (progress)”

  1. Paul W. Frields

    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.

  2. nona

    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”?

  3. dantti

    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.

  4. Faidon Liambotis

    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?

Bad Behavior has blocked 2769 access attempts in the last 7 days.