[Yum] Help with plugin - repogroups

[seth vidal]

On Thu, 2006-10-12 at 09:06 +0100, Luke Ross wrote:
> Hi,
> 
> Over the weekend I've been looking at writing a Yum plugin to support 
> functionality which I've called "repogroups". What I want to do is to 
> organise my repos into groups and then arrange for packages to be 
> preferentially updated by those in the same group. I also want to be 
> able to use these groups to specify preferred repository groups for 
> installing new packages.
> 
> A possible use-case I have in mind:
> 
> - core packages come from a stable distro (with a core and updates 
> repo). Packages from the core are updated from these repos where 
> possible, and new packages are installed from these repos where 
> possible.
> - selected packages are taken from a more cutting-edge distro (also with 
> core and updates repo). Packages from this distro should be updated with 
> packages from these repos where possible. New packages are installed 
> from this repo where either not available in the above, or where a 
> command-line switch changes the preferred repogroup order.
> - other packages may come from other repos which are not in a group (the 
> null group, if you like). these have the lowest priority. upgrades come 
> from these repos only for packages originally installed from a 
> non-group'd repo, and installs from these repos only if none of the 
> groups can support the request.
> 
> Firstly - is there already a sensible way to do this and/or existing 
> code that does so?

protectbase, which you mention below, is the first one to come to mind.


> Assuming not, is there a sensible way to achieve this? Ideally I want to 
> be able to vet the list of candidates for satisfying a given 
> name/dependency and choose the one that meets the requirements best.

There's nothing in the depsolve callback to let you do that, no.
It's a place where the plugin and depsolving code could probably be
enhanced.

> I looked at protectbase's use of exclude_hooks, but these are a bit 
> draconian as it's possible it may exclude packages needed to satisfy a 
> dependency unnecessarily. I also looked at using a postreposetup_hook 
> but that requires basically taking output and redoing the dependency 
> resolution again. It's particularly icky because as far as I can see 
> there's no way for this hook to know what the original reason(s) for 
> including the items in the transaction set are (ie. what dependecy 
> resulted in this member being added?)

I thought you could traverse the tsInfo from that hook. If you can then
you can see the reasons in each ts member.

-sv