On Tue, 2006-10-17 at 11:23 +0100, Luke Ross wrote: > Hi! > > On Mon, Oct 16, 2006 at 10:52:41PM -0400, seth vidal wrote: > > > 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'm assuming that means an appropriate patch adding a new hook would be > considered? Depending on how it was implemented, of course. > > > 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. > > The relatedto field outlines a reason for the addition (eg. 'obsoletes', > 'upgrades', etc), but I can't see anything specifying what the > dependency(s) being satisfied is. To build up a picture of what's going > on, it would be useful to know if the package is bring installed because > foo is required, or foo=4.0 is required, or libfoo.so.4 is required. > The answer could lead to different sets of candidate packages being > built. That's a fair statement. If you'd like to look at ways to enhance the data we're carting around in the transaction member that would be interesting. If we could do it in ways that do not necessarily break the current API that would also be welcome. Let us know what you're thinking as you go. -sv
