[packagekit] preupgrade on Fedora and other distros

[Andres Vargas - zodman]

On 7/13/09, Richard Hughes <hughsient at gmail.com> wrote:
> First, an explanation of the differences between update and upgrade,
> in PackageKit parlance:
>
> update: a simple remove and install that can be done on a running
> system, e.g. update from totem 2.26.1 to totem 2.26.2
> upgrade: updating all the packages at once, with transactions that can
> not be done on the running system, e.g. update from Fedora 8 to Fedora
> 9.

On Foresight its very different, conary the package magement its very
rolling release.

a "Update" can be a install  or remove  package not change package
from 1.0 to 2.0.

For do this change from a version to version we use update System.
with it, all packages change from a version to version and update ALL
packages installed. So we got last package version of whole system.

When foresight do a release. the Update System comes with that release.


> Now, in Fedora we advise upgrading rather than updating in most
> instances, as things like the update from static-dev -> udev and the
> new rpm hash support need to be done with the _new_ versions of the
> packages, with nothing else running.
>
> At the moment, the upgrade framework for Fedora is:
>
> 1. session calls GetDistroUpgrades
> 2. system packagekitd responds with a list
> 3. session pops up bubble, with the latest upgrade shown
> 4. user clicks "upgrade" and the pk-upgrade-distro.sh file is run (as
> the user, not as root)
> 5. If we're debian, we execute do-release-upgrade, if we're opensuse
> we use wagon, and fedora we use preupgrade
>
> now for fedora we have:
>
> 6. ask root password using consolehelper
> 7. run preupgrade application as root
> 8. download new anaconda and packages using yum
> 9. create kickstart file and add entry in grub.conf

the dist upgrade  after process ...  Conary comes with process like
after_install, before_install. instructions so we not have to do that.
So that its automatically.

> Now, this is suboptimal for three reasons:
>
> * We have a fedora specific UI which is not integrated with PolicyKit,
> gnome/kde or the desktop.
> * We are running a python application as root and using consolehelper.
> * It's completely separate from PackageKit, and so preupgrade takes
> the yum lock and blocks out all actions on the daemon until it's
> completed.
>
> Now, I'm guessing the problems we have with preupgrade are common to
> other distros, and we probably need to look at PackageKit to help us
> solve these properly. One very easy thing to do would be to add new
> method UpgradeDistro(distro_id) which was protected by a PolicyKit
> action, which actually did the mechanism. All we would then need to do
> is either port the frontend parts of
> preupgrade/wagon/do-release-upgrade to using PackageKit, or to sit
> down with other interested parties (OpenSUSE?) and design a nice UI,
> and ship it in the kpackagekit and gnome-packagekit projects.
>
> To contend with MacOSX and Windows Vista, I do believe we need to have
> a working online upgrade. I know for Fedora (but probably holds true
> for other non-enterprise distros) that the frequency of releases
> requires us even more-so to have a coherent stack for managing this.
>
> I would appreciate anyone from other distros to tell us what they
> think, and if they are interested in working together on this. Thanks.
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>