yum and yum-updatesd in Rawhide

[James Antill]

On Tue, 2008-02-05 at 14:33 -0800, Andrew Farris wrote:

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

 What was proposed was:

        """
         groupremove by default removes entities that are only found in
        said group and not in other groups or required by things in
        other groups.
        """
        
 So yes, it would, because packages form the groupinstall will be in
other groups ... so thus. won't be removed by the proposed groupremove.

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

 And, again, the proposed change doesn't fix that.

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

 Think of it like this, if I ask for all packages matching "blah*" to be
installed, and then removed ... those are intuitively "inverses", and in
theory they are but yum will have a big problem ending up with the exact
packages you started with for most values of "blah".

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

 Sure.

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

 I'm not saying don't come up with other solutions, just that the
proposed one is worse and more complicated than the current behaviour,
IMO.

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

 Sure I can easily imagine lots of use cases, guessing which one applies
when the user hits return is much less trivial ... see my previous
example, when "groupremove X" is done, does that mean the user actually
wanted system-config-printer to go? -- I could make arguments either
way, and baring something that's right much more often it seems safe to
go for the easy to explain and current behaviour.

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

 Sure, but I'd bet that most cases don't have as big a problem as having
gpgme in KDE. 

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