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.

15 responses to “Preupgrade, meet PackageKit”

  1. Kenny Armstrong

    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. Rob Stewart

    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.

  3. Alex Hudson

    “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?

  4. Rob Spanton

    Hi Richard,

    As preupgrade maintainer, you might want to be aware of this bug in Anaconda:
    https://bugzilla.redhat.com/show_bug.cgi?id=649095

    It stops upgrades working on machines with hard disks > 1.5TB…

  5. Graham Lyon

    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?

  6. Matt

    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.

  7. Doug Warner

    How will preupgrade-cli live on (I don’t know how it’s related to the preupgrade gui)?

  8. Paul W. Frields

    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. ;-)

Bad Behavior has blocked 2769 access attempts in the last 7 days.