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@xxxxxxxxx> 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
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
