On 08/05/2009 01:04 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
> Sure, this is comparable to the present situation. But it doesn't seem
> like it makes things much better.
>
> * It doesn't solve the original poster's issue (that the GNOME stack
> isn't going to be updated for F10 since the maintainers don't want to do
> this and the policy wouldn't require it)
> * It doesn't solve the follow-on issue of things being different between
> major Fedora components (since gnome maintainers don't want to
> participate but kde maintainers do)
> * It makes things more complex (for instance, we would have to build
> packages against multiple repository sets -- ie: [F12-release +
> F12-updates-security] [F12-release + F12-updates-security +
> F12-updates-adventurous] since there could be incompatibilities between
> the packages in updates-security and updates-adventurous.).
> * It makes more work for rel-eng to prepare and push the extra repos.
The major thing it solves is it makes it possible to reliably get only
'conventional' updates. At present, as traditional security / bugfix
updates are mixed up with more adventurous updates, you can't do this.
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just organized slightly differently.
For this:
$ repoquery -qi yum-plugin-security
Name : yum-plugin-security
Version : 1.1.22
Release : 1.fc11
Architecture: noarch
Size : 23792
Packager : Fedora Project
Group : System Environment/Base
URL :
http://yum.baseurl.org/download/yum-utils/
Repository : updates
Summary : Yum plugin to enable security filters
Description :
This plugin adds the options --security, --cve, --bz and --advisory flags
to yum and the list-security and info-security commands.
The options make it possible to limit list/upgrade of packages to specific
security relevant ones. The commands give you the security information.
Either way it's going to be some level of extra work for someone
somewhere, I haven't denied that. Was just discussing the parameters of
addressing (or not addressing) this issue. It's not possible to make all
parties happy in the current framework, so either we change something,
or we take a specific decision to make some parties unhappy, and justify
that formally.
Sure. I'm just pointing out that you're trying to solve a different
problem than either the original poster or Thorsten. (And now that I
understand your problem better, perhaps yours is already solved :-)
-Toshio