[packagekit] availability of a distribution upgrade

[Richard Hughes]

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
PackageKit methods?

> 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:

PkUpgradeEnum:
 ALPHA
 BETA
 STABLE
 UNSTABLE

GetDistroUpgrades()

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
root) methods.

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.

Richard.