KDE vs. GNOME on F10

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090805/37e66933/attachment.sig>