Nicolas Mailhot wrote:
Le Mer 6 février 2008 07:02, Andrew Farris a écrit :
So achieving two understandings of groupremove is not then possible
without more
metadata, because it is ambiguous whether a group is installed
intentionally or
happens to be 'installed' incidentally. Thank you for pointing out
the root
issue with making it happen.
If you want a user-meaningful groupremove, you need to track package
"origin" (was its install explicitely required by the user, was it
installed through a specific group install, was it installed as part
of a multi-group install, what was its repo origin, etc)
Then you can implement all sort of smart groupremove strategies in yum
plugins (taking into account stuff like protectbase, etc), with one
hopefully emerging in a few years as the right heuristic to move into
yum itself.
At this stage I don't think we have enough data to judge the right
user-friendly strategy.
Well I suppose there are many strategies that could be made. At the core of the
issue is that a typical 'user' who does not care how it happens internally is
*most likely* to expect that adding and removing a group will not tear holes
through their other installed groups. The concept of what an installed group is
needs improved, I now realize that.
I don't know what the 'right' strategy looks like, but I know that first obvious
strategy already discussed would be a more user-friendly and more useful tool to
the new / casual linux user than the current behavior. If it were possible to
do yet; unfortunately I guess it is not.
I'm also definitely not arguing that what groupremove does right now is wrong..
I'm just suggesting that it is insufficient as a user tool in many situations
and does not do 'what you want'. It just happens to be the only available thing
to do other than one at a time package removes, and therefore people might use
it without it really being what they want. There is an obvious gap here to fill...
If (as its been said) groups may continue to overlap more, this will only become
more important to improve what options a user has at their disposal.
--
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
