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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
