PackageKit Stop Energy
This should be a reply on Hughsies blog, but I don’t want to create a livejournal account. Richard, please move to blogs.gnome.org!
In response to Jason’s comments:
Hey. I’m a Debian/Ubuntu kinda guy and I think PackageKit is a hell of a lot better than Ubuntu making ubuntu-only solutions like gnome-app-install. It’s DEFINITELY not a NIH, there was nothing that gave us this kind of capability at all before PackageKit started. Everyone knew what was needed to be written and Richard was the guy that jumped in and got it started.
Also Richard wasn’t working at Red Hat when he started PackageKit and has worked with every distro he can on this.
Jason, stop the Stop Energy.
Update:
I though I might jump in and say a bit more on this problem: It really comes down to the question of whether a backend should ask questions of the user. Richard thinks that they shouldn’t, mainly because every time he’s seen backends ask questions they aren’t ones he knows the answer to and so, by inference, most people don’t know the answer to. These questions shouldn’t be asked in a user-friendly system.
However ‘These questions’ are actually multiple classes of problems and simplistically dismissing these is really just asking for failure in solving the problems correctly. Before I go any further, let me note that debconf has multiple levels of verbosity that it can ask questions at. Most Debian based distros just ask the highest priority questions. It should be noted that a PackageKit backend should allow a central administrator to set default values for any of these setting however.
Lets break down some of the kind of questions asked though debconf:
- Configuration file overwrites
- License agreements (cf suns jdk packages, flashplugin-nonfree, etc)
- Technical questions, like whether to start a daemon or not
- Lots of other things?…
Some packages also use stdin/out to really make sure you know what the hell you’re doing, like kernel packages, but i think that’s somewhat outside of this scope of this problem. Those kind of things should just fail unless you’re doing leet-super-admin work 
So the question really comes down to asking the user sensible questions that they a) know how to answer and b) care about.
The point I made to Richard on IRC is that this is actually a difficult and multi-faceted problem and just hiding these problems won’t help in solving them well, so my take is that PackageKit should allow asking of questions, probably via a dbus interface, have a debconf frontend that channels questions by this channel, and then let the Ubuntu and Debian guys get on the case of forming projects and policy to help fix the problem at source.
Update 2:Richard pointed me to this FAQ entry which explains why even handling debconf questions is hard.
April 13th, 2008 at 7:09 pm
Or Richard could just enable anonymous and/or OpenID comments on his LJ…
April 13th, 2008 at 7:30 pm
Mark: yeah, though he already said he can’t figure how to enable OpenId without enabling anonymous, and when he enables anonymous he gets ~50 spam comments a day…
April 13th, 2008 at 9:31 pm
OpenID basically means accepting any anonymous provider of openID, even those fun “validate everyone” providers. It provides authentication, but not trust, not even trust that the authenticated isn’t a computer!
“Stop Energy” is a useful tool in engineering. I see lots of enthusiastic developers writing specs and selling their ideas to Ubuntu, but rarely do I see any meaningful set of downsides, caveats etc. For example, packagekit’s apt backend support is terrible, given the proportion of apt users. Directing stop energy into criticism and evaluations helps, I think.
April 13th, 2008 at 9:51 pm
You can’t enable OpenID without enabling anonymous on LiveJournal at the moment, despite me submitting a patch to do so *counts* 8 months ago. Despite inventing OpenID, LJ’s support has stagnated the past few years, and I don’t see it getting any better with their new owners.
April 13th, 2008 at 10:09 pm
I’m still confused why PackageKit can’t accept user input from a package. The only packages that require this sort of thing are complicated server software type packages. The argument that the “user will be confused” doesn’t really hold much water when you think of things in that way.
April 13th, 2008 at 10:12 pm
jldugger: As far as I understand it, stop energy is unconstructive criticism. I’ve updated my post to add some hopefully constructive criticism and try to untangle the argument
James: that sucks, what a shame
April 13th, 2008 at 10:50 pm
I don’t think the issue has anything to do with debconf, since debconf doesn’t require a terminal for input.
The problem is that there are (a small number of) packages that don’t use debconf. These are the packages that won’t install unless the user interacts with it via STDIN/OUT.
The crux of the problem, in my opinion, is that PackageKit attempts to support all packages on all distributions. dpkg explicitly allows packagers to build packages to work with STDIN/OUT. My guess is that most of the packages in question are server-oriented, not desktop-oriented. If PackageKit were design to work with just the GNOME (or desktop-related) packages, then it might be fair to force packagers to follow PackageKit’s requirements. But PackageKit wants to abstract over all packages on all distributions.
April 13th, 2008 at 10:54 pm
Micheal: Hmm, seems we have a different parsing of what PackageKit wants to be. AFAIK its just about user-facing package install and certainly not about replacing current package installation methods. I guess one simple policy is if a package requires stdin/out the packagekit backend should just fail to install it with a suitable warning. The hard bit would be spotting this of course.
April 13th, 2008 at 11:10 pm
Well, PackageKit doesn’t obsolete anything - you can still use apt-get, synaptic, pirut, zipper or even rpm and dpkg directly. It’s just a layer of prettyness that lets us fix some real problems with the backends. There’s quite a nice intro here: http://people.freedesktop.org/~hughsient/public/introduction-to-packagekit.pdf
April 14th, 2008 at 2:23 pm
Agree with the IPC solution (D-BUS).
Right now Ubuntu’s solution is to run some GNOME application (that is NOT security audited NOR is the GNOME stack of libraries being used security audited either) in a highly predictable way with sudo (therefore, as root).
Worse, they have a (hidden) VTE widget that is running the apt-get or dpkg application as root, too.
Worse, any application and the user herself too can send keystrokes to this widget. Including combinations like CTRL+C. At least on the Ubuntu versions that I tested this against it was even possible to send SIGHUP to apt-get this way (user input breaking the application).
I already filed a bug about this at Ubuntu but that bug was dismissed as invalid. I also, in that bug, tried to discuss a solution for this problem. My ad-hoc solution was to run an ad-hoc SUID root application that gets controlled instructions (over an IPC like pipe() and STDIN or a Unix socket) from the user-application and then executes them.
PackageKid wraps a similar solution (not suid but running a daemon) into a good API, making it possible for any application to securely interact with this.
Questions that are to be asked by the user should in my opinion not be asked by a UI application that runs as root. Something that sits in the middle, converts the questions into something that can’t ever be a security problem and then does IPC with a securely written application to get it done, is a far better architecture for this.
Not only is Ubuntu’s solution a severe security mistake. Running an application as root also creates theming problems, configuration problems (proxy settings, getting user-specific default answers and values, etc).
In stead of for ever postphoning the solution for this problem for the reason “because silly packagers want to ask questions in a non-standard way”, should distributions like Ubuntu attack the problem by supporting a real solution.