Re: yum and yum-updatesd in Rawhide

[Andrew Farris <lordmorgul gmail com>]

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