KDE vs. GNOME on F10
Toshio Kuratomi
a.badger at gmail.com
Wed Aug 5 20:25:20 UTC 2009
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>
More information about the fedora-devel-list
mailing list