Jeff Spaleta wrote:
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.
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.
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.
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?
--
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
