[packagekit] availability of a distribution upgrade
hughsient at gmail.com
Fri Aug 15 00:49:21 PDT 2008
On Thu, 2008-08-14 at 17:44 +0200, Duncan Mac-Vicar Prett wrote:
> Hi guys. I have an use case we want to solve, and since our updater
> applets are now packagekit based, I would like something at the
> packagekit level.
Yes, there's a enhancement bug for this functionality for Fedora too.
> Our SUSE Linux Enterprise upgrades are called service packs, so SLE10,
> SLE10 SP1, SLE 10 SP2 and so on (I think RHEL is 5 , 5.1, 5.2 etc ).
> Nothing to do with the .pack files that package kit call "service packs"
> (which don't fit for this particular case)
No, a different use case.
> The upgrade requires various steps depending on the update scenario
> (running system, boot from media etc), but at least it requires that if
> you are upgrading from our servers, that you get the right repositories,
> and for that you need to re-register and other extra steps. In addition
> to that, the upgrade is done using libzypp's dist-upgrade algorithm and
> not with the normal upgrade. Therefore we will have a YaST work flow to
> do that.
Right, sounds like Fedora's preuprade.
> Now, we want to notify the users about the availability of the service
> pack via the normal updates, and trigger from there our work flow.
> As our GetUpdates method is based on patches objects (updateinfo
> grouped) and not packages, this may be solved in various ways.
> One is for example, having the patch in a special category, the patch
> will update a couple of necessary packages, like a normal patch, but
> then the backend could look into its category and trigger something.
I don't think checking for major OS _upgrades_ is in the same use case
or abstract form as checking for minor updates and so I don't think the
GetUpdates method should be used for this.
> Till now I haven't touched anything in PK that is not already there, the
> only thing that is missing, is to launch the workflow. This could be
> done by the backend, but I think it is better that the workflow is
> started by the application that started the patch, in this case the
> applet, with the user permissions, and in case the work flow needs root,
> it can be started with the desktop specific su.
Does the workflow need root -- or could all the root stuff be done with
> What I mean here, is that may be PackageKit backend could signal the
> request of launching some external program back to the client
> application, which can be handled by the application with the right user
> interface, semantics, confirmations, etc. (for example, pkcon can just
> tell the user "run this program" instead of actually running it)
> May be there is a better way ? :-)
I think so. Maybe a new API:
DistroUpgrade(PkUpgradeEnum, distro_id, summary)
So if I schedule an OS upgrade check (when running Fedora 8) for once a
week (easy to do in the current code) I would get back:
DistroUpgrade(UNSTABLE, "rawhide", "Fedora rawhide is a bleeding edge
version of fedora Rawhide. If it breaks, you get to keep both pieces")
DistroUpgrade(STABLE, "fedora-9", "Fedora 9 is the latest and greatest
version of Fedora")
DistroUpgrade(ALPHA, "fedora-10-rc1", "Fedora 10 RC is recommended if
you want to try an unstable version of Fedora")
And then I can show a nice GUI explaining what all the options are. The
distro_id can then be passed to a GUI helper which does all the right
things (and asks for root if needed) or just uses PackageKit (without
What do you think? Any way you would expand this API? I don't think this
blocks 0.3.0 -- we can always add this in 0.3.1.
More information about the PackageKit