yum and yum-updatesd in Rawhide

[James Antill]

On Tue, 2008-02-05 at 12:46 -0800, Andrew Farris wrote:
> Jesse Keating wrote:
> > On Mon, 04 Feb 2008 23:42:05 -0800
> > Andrew Farris <lordmorgul at gmail.com> wrote:
> > 
> >> Perhaps the only good solution to that is to have two groupremoves...
> >> one that removes the *unique group members* and one that removes the
> >> *entire group*.  I cannot think of any reason there would be the need
> >> for additional interpretations of groupremove.
> > 
> > yum groupremove --all or --force
> > 
> > groupremove by default removes entities that are only found in said
> > group and not in other groups or required by things in other groups.

 This is far from trivial, and what happens when you do:

yum groupremove 'X Window System'

...does that remove system-config-printer? I'd assume not from the
above ... at which point dbus-x11 + pygtk2 + etc. are all kept, at which
point what is groupremove buying you over just using yum remove and
maybe yum groupinfo?

> > Least surprise.  --all or --force will remove all entities in said
> > group regardless of overlapping members.

 Well yum doesn't do positional options atm. so you'd need much bigger
option names ... and you assume the desired normal behaviour would be to
not remove what the user has explicitly asked to be removed, which seems
wrong.

> I think that would be a good change to make, and would certainly be a better 
> safeguard for users only working in an interface to yum who might not understand 
> groups overlap at all.
> 
> A new user would expect that when they install a group, whatever got added will 
> be what goes away when they remove the group.

 Which the above _doesn't_ do, if indeed the user expects that (which I
don't think is true).

>   The group install and group 
> remove are reasonably expected to be inverses.  An additional 'yeah I want to 
> nuke it' flag would be great for this.

 If I start with no packages and do:

yum groupinstall Foo
yum groupremove  Foo

...then I _currently_ end up where I started, so they are _currently_
inverses of each other in that theoretical model ... and the above
change would break that.
 The problem comes when you start with package set X1 (some of which are
in the group you are installing) and groupinstall takes you to the
superset X2, groupremove cannot currently get you back to X1 (even if
you assumed nothing changed in between), without more data and
significantly more work.

 In short it seems much easier to just make sure gpgme isn't explicitly
listed in the KDE group.

-- 
James Antill <james at fedoraproject.com>
Fedora