Month: August 2007

For PackageKit we don't want to be refreshing caches or checking for updates when there is no network connection. Does anyone have a short guide on how to monitor and query the connected state of nm (session or system), just like evolution does? Any nm guys want to write me a quick patch or jot down some quick code? Cheers.

EDIT: Done, thanks guys.

git clone git://people.freedesktop.org/~hughsient/PackageKit

Patches accepted. Thanks.

edit: Now git clone git://anongit.freedesktop.org/git/packagekit

Work on PackageKit continues. The new manager application has lots of human-unfriendly options now, but allows people to experiment with all the features and more importantly allow people to look at the code and work out how to port their app to support PackageKit.

There's quite a few API additions now also, with different search modes and also error codes and descriptions. The API will grow some more soon also, to get the extended description of a package along with a URL and any further information not contained in the summary. Then I think it's complete.

I've now split the dummy and yum backends, so in theory the yum backend could be soon complete. I'm adding the yum scripts as skvidal is kindly writing them, and hopefully everything should soon be in place for the other backends.

So, answering some FAQ's (I've had hundreds of emails about PK in the last 2 weeks):

• Hopefully gnome-app-install will use the PackageKit API soon. Sebastian Heinlein is already volunteering to do the porting.
• A conary backend can be created really soon. I just want to finish a little more the yum backend and move some of the shared spawn code so the minimum code is duplicated. I'll also need to add a shitload of documentation.
• A trivial apt backend will be created by me doing screenscraping of apt-get. A much better backend can be created by someone who knows C++ and is familiar with libapt.
• You don't have to have a backend that supports percentage updates. If you don't know the progress, just emit NoPercentageUpdates and then the UI should just do the right thing and spin.
• Backends don't have to support all options of all methods. Just set an error and return false if not implemented.
• Error codes have to be standardized so they can be localized. The error detail field can just be the untranslatable output. If you are creating a backend and you need another error enum, yell, and we can add it to the supported list.
• Upgrading, installing or removing packages has to be silent. The user cannot be prompted for questions “set applet setuid?” as these will not be handled in PackageKit. This is not an issue for rpm but will be for apt. The backend should do the right thing, as these messages mean very little the the average user and cannot be translated.
• PackageKit does not replace up2date. PackageKit is a way for users to interact with the packaging system, not for an administrator to install software on remote machines.
• PackageKit is not yet another system daemon. It quits when not doing anything, and only starts when something wants information or a task completed.
• PackageKit does not do dependency resolution. This problem has already been solved by the backend systems and I don't really want to re-invent the wheel.
• PackageKit does not have the fine-grained API to do everything. For instance, synaptic should still use libapt as can do much more than can be provided by PK.
• PackageKit is not a replacement to red carpet. Red carpet was really great and years ahead of it's time, but tried to do everything package related on the system, and moved onto the enterprise centralized management model. Although cool, this latter point made things too political IMO.
• PackageKit is not vapourware. I'm just waiting for fd.o git space and if that doesn't come about soon I'll just dump the code on code.google.com for a temporary solution. Then I'll start taking patches. All the applications work, they are not mockups. There are F8 rpm's in my repo also if you want a sneak peak.
• PackageKit is fast. It takes about 1 second to search for installed and available packages with “power” in the description – no blocking of the UI happens at all as it's all async. All the applications start instantly with no root password needed at startup.
• PackageKit is designed from the ground up to work with fast user switching and logging in and out of sessions during upgrades. You can start a system upgrade, log out, log in as another user, and be notified when the upgrade is complete, all without risking your rpmdb.
• PackageKit does not stop you using the low level tools yourself. You can use rpm and yum or dpkg and apt when PK is inactive (99.999% of the time) when you really need some command line love. No more fighting over yum, yum-updatesd, pup and pirut.
• PackageKit is not sponsored by anyone. Whilst interning at RedHat I spent a few days on the API and some UI designs, but all the coding is done in my free time.

So, good things.

PackageKit now has an update applet and application installer. This demo-application will win no awards for UI design, but the idea is to show how easy it is to make an async frontend for the provided dbus interface.

Also, the trivial update icon runs once per active session, and communicates with a single system instance of PackageKit. When the service is needed it is activated using dbus system activation, and when it's doing nothing the system daemon quits.

This means we can queue multi-session updates and installs. For instance I can start an update in my user session, switch to my girlfriends session, and then search for pidgin, and queue the install. The install will start when my update has completed. Maybe a more useful situation would be for the gdm login to start doing the daily updates before a user even logs in. OpenOffice could install language packs in the background as soon as you start typing in a new language. Lots of fun stuff.

Of course very little of this actually works properly. The dummy backend does mostly the right thing, and the apt and yum backends can search, but I still need to do the rest of the actions. The PolicyKit bit is still to be done.

So, good things.

What I've done:

• Defined a DBUS API
• A system daemon that manages asynchronous jobs, and sends out notifications of job status changed
• A dummy backend doing all the actions but just time-wasting (acts as a nice self-test)
• A yum backend that can do async searching (nothing else yet)
• An APT backend that can do async searching (nothing else yet)
• A client gobject library for easy integration for GNOME stuff
• A command line client that can work async or sync.

What's left to do:

• Full API for yum and apt
• A better apt backend that can do percentage completion signals (requires using libapt-pkg and C++…)
• Other backends (portage, smart, urpmi etc)
• Better documentation
• Update applet proof-of-concept (should be easy using the gobject library)
• Simple application installer proof-of-concept

So basically the idea works. Or at least I've not come up against any insurmountable problems so far. Expect the code to hit fd.o in the next week or so when I've polished up the hacks and got rid of a few FIXME's.
I'm away from an Internet connection for the next few days, so if you send me mail it will take me a few days to reply.

PackageKit is the name of the system package abstraction. Why PackageKit? Well, I was getting jealous of all the other cool stuff happening with daemons ending in Kit and wanted my own. And, if I type the word “manager” once again I'm going to have to rip my hands from my arms. :-)

There is a wiki page with all the use cases so far and some UI designs. Feel free to add comments or suggestions at the end of the page.

I've spent most of today working out a asynchronous DBUS API that can work with all of the use-cases, and starting a system activated daemon that can manage the sequential jobs. The daemon now 80% works, and I'm just writing a “dummy” backend with a “do nothing but take time doing it” role for testing. The other backends (yum/apt) are in the source tree but are currently empty files.

I only know a little about APT, so now I need your help. I need a way of searching for installed and not-installed software. I think I need either:

• a C binding for APT (I'm guessing that doesn't exist)
• a way of APT letting me search for “power” and returning tab delimited output.

The output would ideally be one line per entry:
gnome-power-manager<tab>GNOME Power Manager<tab>GNOME Power Manager is a system daemon that eats lots of power
power-pacman<tab>Power Pacman<tab>Power Pacman is a cool game where a dot eats other dots

The same thing for YUM would also be great as well, although I'm focusing on the apt backend first as I think it's the easier target for now. Thanks!