[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yum and yum-updatesd in Rawhide

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]