Re: yum and yum-updatesd in Rawhide

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

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux