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

Re: yum and yum-updatesd in Rawhide



Jeff Spaleta wrote:
On Feb 3, 2008 7:19 AM, seth vidal <skvidal fedoraproject org> 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 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
----                                                                       ----


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