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_plain;f=helpers/README] 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. -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
