yum and yum-updatesd in Rawhide

[Andrew Farris]

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