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
