[packagekit] availability of a distribution upgrade

[Duncan Mac-Vicar Prett]

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.

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)

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.

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.

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.

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

cheers
Duncan