[packagekit] Yum backend RequireReboot

Richard Hughes hughsient at gmail.com
Wed Oct 3 10:14:45 PDT 2007


On Wed, 2007-10-03 at 09:47 -0400, Luke Macken wrote:
> On Wed, Oct 03, 2007 at 08:11:08AM +0200, Tim Lauridsen wrote:
> > David Zeuthen wrote:
> >> On Tue, 2007-10-02 at 18:57 +0200, Tim Lauridsen wrote:
> >>   
> >>> yum/rpm don't care if the system need a reboot to use the updated
> >>> packages, it is only i high level gui, this kind of stuff is
> >>> interesting.
> >>> we could make a /etc/packagekit-backend.conf and write a list of
> >>> reboot packages into the conf file.
> >>>     
> >>
> >> I think the point is that it's a lot more preferable to be able to
> >> specify this on a per-package basis (e.g. in the RPM spec file for each
> >> package requiring a reboot) and then have this data propagated into the
> >> update meta data.
> >>
> >>      David
> >>
> >>   
> > That will be the best way to do it, but it will need some changes to rpm, 
> > rpmbuild, createrepo & yum.
> > Maybe adding it as a selection in bodhi and get it into the extra update 
> > metadata, is a easier way to go :)
> 
> Bodhi has been adding a reboot_suggested field into the updateinfo for a
> while now.
> 
> I've been crazy busy hacking on fedora infrastructure for the past few
> weeks, but I'm going to sit down and work the extended updateinfo
> metadata into PackageKit very soon (unless someone got it it before it).
> This will give us advisory details, bug/cve ids and links, sha1sums,
> among other things.

Yes, we need this for GetUpdateDetail:

    <signal name="UpdateDetail">
      <arg type="s" name="tid" direction="out"/>
      <arg type="s" name="package_id" direction="out"/>
      <arg type="s" name="updates" direction="out"/>
      <arg type="s" name="obsoletes" direction="out"/>
      <arg type="s" name="url" direction="out"/>
      <arg type="s" name="restart" direction="out"/>
      <arg type="s" name="update_text" direction="out"/>
    </signal>

We can extend this as required. Yell if you want to add anything.

Richard.





More information about the PackageKit mailing list