[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