seth vidal wrote:
On Sun, 2008-02-03 at 14:21 -0800, Andrew Farris wrote:
A thought for Seth:
Wouldn't it be possible for the groupremove operation to handle this with
information it already has? If a package is added to a remove operation list
because the original command given is a groupremove, then any packages that are
also listed in another group (that is installed) should be skipped over in the
remove operation. It means retracing over the remove list once the reverse deps
are solved and checking whether each package is a member of an installed group
other than the one being removed.
The problem is we get into a "do what I mean" weird case:
Did the user type 'groupremove foo' b/c they wanted to remove all the
pkgs in foo, regardless of whether or not they exist in other groups? Or
did they type 'groupremove foo' b/c they just wanted the pkgs in this
group, not used by other things, to be removed?
And you end up fighting between those two classes of users.
Handling it in that way might be extremely slow, but it shouldn't require
another database of information for context on how the package was originally
installed right? Assume if its part of more than one *installed group* then
leave it in place during the first groupremove.
Again - that's great for YOUR case but the way I used to use groups was
to make a host into a profile based on the groups it has available.
so when I said groupremove 'physics beowulf' I MEANT remove all of the
pkgs in that group, regardless.
You'll get the result of any packages that exist only because they are a member
of the group being removed are removed, and any dependencies those packages
pulled in will be removed only if they are listed in no other group that is
installed. Would that end up leaving any cruft behind?
Of course it'll leave cruft behind, depending on your definition of
cruft. My definition of cruft includes anything I didn't intend to leave
installed and my intention as explained above was to remove everything I
specified. If I didn't want all the contents of the group to be removed
I wouldn't have typed 'groupremove' at all.
I concede that there are two divergent (and in my mind equally valid)
understandings of what removing a group should entail. The problem is, if
groups continue to overlap significantly, that removing a group will become
essentially something that is just not *useful* except the rare case of
cannibalizing the system to make it into something it wasn't before (i.e.
desktop -> server transition).
Perhaps the only good solution to that is to have two groupremoves... one that
removes the *unique group members* and one that removes the *entire group*. I
cannot think of any reason there would be the need for additional
interpretations of groupremove.
If its not 'safe' to groupremove kde when you want to just keep using gnome and
not lose necessary supporting files (like uninstalling yum), its a much less
useful feature for Fedora to have groups at all in the package space. People
are alot less likely to install a group they may not want to keep forever if
they are unsure how to get rid of it without clicking on every single package
separately in pirut. Groups become essentially an installer commodity, and
otherwise are there only for rapidly tearing a system apart.
I'm reminded of the installer bugs on that ubiquitous platform that leave apps
listed in your control thingy without the ability to remove them because they no
longer exist but cannot figure out they are already removed. (which is
completely unrelated to groupremoves, but ironic anyway, like the control thingy
removing itself would be)
So, I'm just suggesting that groupremove is ambiguous and deserves to be two
groupremoves. (and apologize that I will not be offering a patch as I have yet
to learn python)
--
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
