Preupgrade, meet PackageKit

Yesterday I merged a patch to PackageKit which added the UpgradeSystem() method to the transaction interface. This is the natural compliment of the GetDistropUgrades() method which was added last year. This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword and running GTK and python graphically as the root user.

In Fedora, we use a package called preupgrade. This was created by Will Woods and Seth Vidal in 2008, and I was asked to maintain it last year. I’ve been helped by James Laska, which has been very much appreciated. Preupgrade has been fixed up a few times, but the majority of the code is the same as when I inherited it. Preupgrade was a nearly-good-enough monolithic lump of code that kinda worked.

In my humble opinion, Fedora (and all other distros) are too small to maintain such mission critical stuff such as distribution upgraders. The PackageKit project has shown people that by distributions combining forces, they can share frontends and write different small backends and free up developers for other things. As a team, we have a better quality product than the results of one developer on one distribution.

So I figured preupgrade should have the same love. 99% of the preupgrade code is GUI interface code and this was easily converted to C, and to use PackageKit. The result of this is in gnome-packagekit git master, with a new tool gpk-distro-upgrade.

screenshot

Don’t go and try this code just yet. None of the preupgrade backend code has been moved to the yum backend, although I don’t assume I’ll have many problems, and plan to do this later in the week. If you want to test this use the “dummy” backend, although this won’t actually perform any changes of course.

Hopefully some of the other distros can play with gpk-distro-upgrade and improve it. Hopefully the translators will file bugs about the bad English, and translate it to 50 languages. Hopefully another distro will port their os updater to use this new functionality and find bugs or speed up the common code a little.

All I know is preupgrade will live on as part of PackageKit, and now it’s targeted at a bigger audience than just the few million of Fedora users.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

15 thoughts on “Preupgrade, meet PackageKit”

  1. I have to say, I was sceptical of the preupgrade tool at first. I had always done fresh re-installs.

    However, I use a Fedora PC at work very heavily, and it was running Fedora 12. So to test it, I ran preupgrade on my personal laptop that was running Fedora 13 just to see what it was like. I figured “if it blows up, I’ll just reinstall.” It went extremely smooth and I didn’t have any real problems (just the whole /boot partition not quite being large enough, but that was easily fixed). So I then did it to my work PC, and it also went smoothly. I then upgraded my work laptop then my home PC this way.

    So to be sure, I’m quite grateful for the preupgrade tool. It has been a substantially big help to me.

  2. Richard, this is great. I’ve been using preupgrade since its inception (Fedora 11 perhaps?). It is one of the most invaluable tools installed on my machine. I may only use it once every 6 months, but boy do I depend on it to work ! And it worked for me yesterday, typing now on my shiny new F14 setup.

    I’ve always thought Ubuntu do a pretty good job with distribution upgrades, though I suspect it’s tied in to aptitude quite heavily (might be wrong). Part of the reason why I think it is good is that dist-upgrades are tied into the “update manager”.

    So now you are planning on working with packagekit as the frontend, are you thinking that distribution upgrades in Fedora can be more closely associated with the package update manager in FedoraI ? Currently there are two packages in Fedora, one for yum updates and one for dist upgrades, in Ubuntu, there is one, for both.

    Great work, Richard.

    1. >are you thinking that distribution upgrades in Fedora can be more closely associated with the package update manager in Fedora

      Yes, it’s the same thing, but on a different scale. When the backend code is done, we’ll look at how all the frontend code interacts.

  3. “This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword”

    I’m kinda surprised that you think asking for an admin password before barrelling into the IT equivalent of open-heart surgery is a “dumb thing”. Have I totally misunderstood your point here?

    1. Well, PackageKit still asks for admin authorization to do the actual upgrade, but to the see the list of upgrades no password is required. PackageKit uses PolicyKit, so the admin could quite easily change the upgrade-system policy to “no” or to just require the user password like sudo.

      1. Ah, that’s cool then. Hopefully this will spur people on to ensure that distro->distro package upgrades are cleaner than they are now; Fedora still feels quite behind the debian-based distros in this regard (I still cross my fingers on upgrade).

  5. Sorry for my ignorance, but you say that this can be done without doing “dumb things” like “asking for the admin password”. Does this mean that ANY user can perform an upgrade on the system, or do they still need to be a member of some trusted group?

    1. See my reply above (sorry, all comments get stuck in a moderator queue…) but basically my point was that running the whole pygtk app as root is a huge issue, and that’s what’s dumb. Of course, we’ll need the admin password to do the actual downloads and blitting to disk.

  6. I hope what he meant is that it can gain authorisation to do it through PolicyKit or some other nice robust mechanism instead of rolling its own mechanism…

    This looks like good work, but really somebody needs to do something about GtkAssistant before it gets carried away by the ugly police.

  8. I LOVE IT! I have a couple systems in the house that are on older Fedoras (12 and 13) where I look forward to trying this out. If you’re looking for guinea pigs, do post again. I love alfalfa. ;-)

Comments are closed.