On Feb 3, 2008 7:19 AM, seth vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote: > File it against comps, if you want, I'm not sure what resolution there > can be, though. The underlying problem here is that we used the simplest approach to uninstalling that doesn't take into account whether a package is part of another 'installed' group (whatever that means). Since we don't keep track of the context of the install operation...was it installed as part of a group install operation, explicitly requested by a user for install, or dragged in to fill a dep, other crap like that... we've no way to account for that context in the remove operation. So all removes are equal. I think group definitions overlap is unavoidable...its too big of a space. If we continue to require that groups don't overlap like this, we really limit how Spins/SIGs can leverage group definitions to organize their space. But for a groupremove command to work, rationally, there has to be some extra information tracked about why a package was installed, so when its uninstalled as part of a groupremove, its not uninstalled if it belongs to another installed group. We just don't have the information...yet. I know tracking this sort of install context has been brought up before (by me even!). Seth do you know anyone who is experimenting with this sort of thing? Tracking the context of a package install in terms of explicit request, dep resolution, or group member? -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
