Hi guys.
I've been pointed to the "low-hanging fruit" discussion on this list
by a couple of people. I wasn't on this list, but now am.
So what is PackageKit:
• A daemon that accepts asynchronous jobs.
• A way of letting certain groups of people do stuff to the package
database with a fine grained server-client security model.
• A system service that starts only when needed.
• A way of inhibiting suspend/hibernate/restart/shutdown when
performing actions.
• An interface to a packaging backend.
The fine grained security model allows an installer application to be
loaded as the user (without a root password), to do searches without a
password, and to only ask the user for authentication for any
privileged task, for instance updating the system or installing a
package. This lets the admin decide what level of security is best for
the box in question.
[http://people.freedesktop.org/~hughsient/temp/pk-polkit.png]
A packaging backend can be something in a thread like libapt-pkg (as
it has a C++ binding) or using a polling backend with external helper
scripts for stuff like yum (python) or urpmi (perl) with no C
bindings.
The helper scripts communicate over stdin, stderr and stdout using a
loosly defined (by the backend) protocol, in an effort to make
scripted synchronous operations into async ones with a common DBUS
interface. I've started to define this here:
[http://gitweb.freedesktop.org/?p=users/hughsient/PackageKit.git;a=blob_plai…]
What is Packagekit-gnome:
• An lightweight update applet that runs once per logged in user that
refreshes the cache at startup and displays update status and critical
security warnings.
[http://people.freedesktop.org/~hughsient/temp/pk-updates-warning.png]
• A way of seeing what other users are doing with PackageKit, so you
can see why the hdd light is flashing after doing a fast user switch
somewhere else.
• An application installer. Note, gnome-app-install is probably going
to be the long term target as this will be ported to the PackageKit
API. [http://people.freedesktop.org/~hughsient/temp/pk-application2.png]
So, misconceptions in the thread so far (in my opinion):
Pirut and PackageKit are mutually exclusive:
You can happily run them both side by side. I am now. If pirut is open
then PK should queue the request until pirut is closed.
PackageKit is vapourware:
Nope, I'm running it right now. True, only the dummy backend is
supported but the apt and yum backends are coming on. The deps are
also pretty harsh; you need PolicyKit, dbus-glib, dbus and
PolicyKit-gnome all from git. F8 rpm's for PackageKit are in my repo
[http://people.freedesktop.org/~hughsient/fedora/].
PackageKit API is rubbish:
I know. It's unstable right now, and is changing to fulfill all the
use-cases. My view is you have to let an API evolve to be optimal,
rather than over-engineer everything when the complexities are not
known. [http://people.freedesktop.org/~hughsient/temp/pk-interface.xml]
Error enums will not be powerful enough
Fair enough, I hear you loud and clear. Maybe we can set a hint to the
backend about the locale, but I would have to think about this more.
PackageKit will be included in F9/F10/desktop-spin/crackpot-spin
That's up to you guys. I think it will be some time before the API is
stable, and all the UI and policy bits and bobs are worked out.
PackageKit also needs a security code review as sometimes it's running
as the root user. So, the short story is I'm not pushing this to be
included in fedora right now, as it can only do 10% of what the
current tools can do.
PackageKit allows you to install stuff without a password
Well, it allows the admin to set what sort of authentication you need
to do each action, be it your own password, an admins password, or
just to deny the request.
PackageKit is yet another system daemon to be started at boot time:
Nope, it's started only when needed using system activation, and quits
a few seconds after finishing it's last queued task.
We are just a layer over yum -y --ask-no-questions:
If PackageKit is just a layer, I think the layer allows us to do some
important things the old system could not, and allows us to share code
between distros and desktop projects.
Also, my view is that questions should never be asked. Who has ever
clicked no to "Load GPG key from Fedora Project"? Is there a legal
requirement to show such a warning?
So, I hope that has cleared things up a bit. Comments and suggestions welcome.
Thanks,
Richard Hughes.
