[Yum] Help with plugin - repogroups

Luke Ross luke at lukeross.name
Thu Oct 12 08:06:34 UTC 2006


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?

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.

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?)

Any thoughts?

Thanks, an apologies for my vagueness.

Luke



More information about the Yum mailing list