[packagekit] ServicePack: The magic file

[David Zeuthen]

On Thu, 2008-03-27 at 17:54 +0000, Richard Hughes wrote:
> Yes, that's the plan also, see
> http://lists.freedesktop.org/archives/packagekit/2008-March/002434.html
> 
> How do i define an x-content type?

See Nautilus

http://svn.gnome.org/svn/nautilus/trunk/data/

The plan is that e.g. instead of just

  <mime-type type="x-content/video-vcd">
     <!-- http://en.wikipedia.org/wiki/Video_CD -->
     <_comment>Video CD</_comment>
   </mime-type>

we will include some rules on how to match this media. E.g.

  <mime-type type="x-content/video-vcd">
    <!-- http://en.wikipedia.org/wiki/Video_CD -->
    <_comment>Video CD</_comment>
    <check_existence dir="VCD"/>
  </mime-type>

so for PackageKit we would want

  <mime-type type="x-content/packagekit-servicepack">
    <_comment>Service Pack</_comment>
    <check_existence file="packagekit-servicepack.conf"/>
  </mime-type>

This is what I meant with the work needed to get this into upstream
shared-mime-info. Right now we just hardcode the checks in Nautilus,
e.g. _g_mount_guess_content_type() in

http://svn.gnome.org/svn/nautilus/trunk/libnautilus-private/nautilus-autorun.c

but this is expected, for GNOME 2.24, to a) go into gio; and b) use
rules from shared-mime-info. So for early F10 Rawhide we'd just patch
Nautilus to do the check for x-content/packagekit-servicepack.

> >  - Proper prompts
> > http://people.freedesktop.org/~david/nautilus-utopia-4.png
> 
> All looks cool, but still relies of a client/server split - we can't do
> the locking and repo adding session wide, it has to be per-system. In
> the case I outlines in my initial mail, it's done both per-session _and_
> per system to be able to rock hard.

I don't know what that means. I'm just saying that this enables the user
to start a program when service pack media is available (either via an
autoprompt, by the cluebar or whatever). Your program can do whatever it
wants including poking pk-update-icon or whatever.

> >  packagekit-service-pack.conf
> 
> packagekit.conf sounds like a plan - as it'll be used for more stuff
> than just service pack media.

One point here was that in order to detect that media actually contains
a service pack we need to key off something simple on the media. In that
respect packagekit-service-pack.conf is a lot more useful; otherwise
we'd detect any media with packagekit.conf on the root dir of the media
as a service pack. Which is not ideal.

Hope this clarifies.

       David