Comments on: PackageKit and debconf (progress)

By: hughsie

hughsie — Fri, 16 Oct 2009 08:18:27 +0000

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.

By: hughsie

hughsie — Fri, 16 Oct 2009 08:13:11 +0000

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.

By: Faidon Liambotis

Faidon Liambotis — Thu, 15 Oct 2009 17:39:56 +0000

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?

By: dantti

dantti — Thu, 15 Oct 2009 17:03:10 +0000

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.

By: nona

nona — Thu, 15 Oct 2009 14:47:15 +0000

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

By: Paul W. Frields

Paul W. Frields — Thu, 15 Oct 2009 14:15:04 +0000

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.