yum and yum-updatesd in Rawhide

[Andrew Farris]

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.

In other groups is not the problem, in other *installed groups* is.  In your 
example case there are no other installed groups... the behaviors are identical.

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

I suppose that might be because I'm not understanding how we decide if a group 
is installed or not.  The above behavior WOULD correctly result in the inverse 
operation if its understood whether a group is installed or not.

I am not suggesting that every file be compared by whether it *can be in another 
group* only whether or not *it is a member of an installed group*.  The 
difference is whether the group it overlaps with is installed or not.  If it is 
not installed, then overlapping is not a problem and the package would be 
removed by reverse dep solving... i.e. exactly the case when yum gets removed 
because gpgme was a dependency.  But that should be prevented if any other 
installed group also wanted yum to be installed.

For instance, When Foo is installed it will bring in dependencies.  If those 
dependencies are part of another already installed group then they should have 
already been installed.  If they are NOT part of another already installed group 
then they will be added by the groupinstall operation.

When you groupremove, and those dependencies are looked at for removal, it 
should remove any dependencies of the Foo group ONLY if they are not part of 
another installed group.  Being part of another group is not the question; the 
question is part of another installed group.

In this case, those packages would be the set of dependencies that were already 
installed for another group BEFORE Foo was installed that should be left behind.

This may be exactly the type of metadata that Spaleta is talking about, knowing 
the context of the install.  As I understand it, knowing whether a group is 
installed or not would be adequate to achieve this result, but not necessarily a 
very fast algorithm to work with.

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

Which is why I'm suggesting that no guesswork be applied... I'm not talking 
about black box 'do what I want' behavior.  I'm suggesting that there are two 
well defined, different behaviors, and it would be very beneficial to have them 
available.  At the moment, we only have one of them.  The one available happens 
to be the heaviest hammer option.  Currently you'd need sed, xargs, and pipes to 
achieve the lighter hammer, without having to type every separate package name 
you want removed to get rid of a group.

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