yum and yum-updatesd in Rawhide

[Andrew Farris]

James Antill wrote:
> 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.

No it would not.  If you have no other groups installed the above change would 
do exactly what it should and leave you with no packages installed.  The same is 
true for BOTH understandings of groupremove behavior.

On the other hand if you DO have other groups installed that overlap, and then do:
 > yum groupinstall Foo
 > yum groupremove  Foo

You do NOT end up with inverses.  This is counter-intuitive to someone who asks 
for something (a group) to be installed and then removed.  Despite the fact that 
they are specifically asking for this behavior it is not what one would expect 
the behavior to be...

And that stems from the problem that groups overlap in the first place.  (also 
counter-intuitive on the surface level)

>  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.

Ok, I can see where there may be corner cases the straight forward solution I 
suggested does not work.  However, I think it is the best way forward for *some 
solution* to be developed.

Any way you want to look at it, a user might actually WANT to remove only the 
parts of a group that do not overlap.. the stuff he does not want around.. while 
leaving his other groups intact.  At this time the only way to make that happen 
is to manually list every package he wants removed, and this is definitely 
sub-optimal.

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

Yes, but groups are permitted to overlap in the future.  A real solution needs 
to exist.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----