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 don't have any objection with making the commands smarter based on more context information. I just want to be clear about what 'smarter' actually looks like. To a number of people 'smarter' is actually second-guessing the user and therefore dumber think about the problem from that perspective some. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list