PackageKit progress 2

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.

insane UI decisions…

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.