yum module idea: force-install high-priority updates

Luke Macken lmacken at redhat.com
Thu Nov 9 00:01:51 UTC 2006


On Wed, Nov 08, 2006 at 01:05:46PM -0900, Jeff Spaleta wrote:
> On 11/8/06, Michel Salim <michel.salim at gmail.com> wrote:
> >There might be a problem if the conflicting package is not available
> >from any repository, but in general, does the idea seem sound?
> 
> Technically... this is possible... the 'security' label is available
> in the updateinfo.xml.gz now being generated for updates to fc6.
> 
> Whether or not such a plugin is rational or even sane, will be a
> matter of opinion based on individual administrator situations.  This
> would never be appropriate as something to install by default, and
> should only be used by people who know wtf they are doing.
> 
> You would most certaintly want the plugin be advenced enough so admins
> could identify a list of 'important' packages which should not be
> allowed to break in the effort to force a security update.   Its one
> think to break liferea it's another to break the deps to httpd, if the
> machine is primarily a webserver.

I'm in the process of finishing up some api changes to the update
metdata module for yum (yum.update_md), and I have a couple of yum
plugins/tools I'm going to be getting out the door shortly (once/if I
make it through finals next week).

The first is a 'securityonly' yum plugin, which will only install updates
flagged as security.  At the moment the updateinfo.xml.gz metadata,
which contains this information, is only being generated for core updates,
thus making this plugin only partially useful.  I'm currently working on
coding up a new and improved updates system[0] for Fedora (encompassing
core/extras/legacy) that will give us this metadata for all updates.

As for having it purposely break things for 'important' updates, I'm not
sure that's the best approach to solving the problem.  At the least, I'd
like to making sure the user/admin is *well aware* that they have security
updates that are unable to be installed (and offer a potential solution).
But in a Perfect World (with unified build/update systems, QA, etc),
dependency issues like the liferea one Michel mentioned wouldn't happen.

The second tool I'm working on is a standalone script to query package update
notices via the commandline (by CVE/bug/package/etc).  More on that in
the near future.

luke

[0]: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem




More information about the devel mailing list