yum and yum-updatesd in Rawhide

[seth vidal]

On Tue, 2008-02-05 at 18:10 -0500, James Antill wrote:
> 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.
> 


So let me add my 2c here.

1. James is 100% correct
2. the groupremove-do-what-I-mean-not-what-I-said mode will NOT be added
to yum. 

-sv