> ]] George Danchev > > | I now realize I missed to have a look at the comment given in #214566, > | which basically asks for: > | > | "a way to handle or'ed build-dependencies in a useful way". > | > | Well, I guess there is a useful way to handle OR'ed build-deps if we > | engage the package/versions availability machinery (via AptPkg) which > | would conveniently add sensible means to take a safe course of > | action. Having these available, we can simplify OR'ed (and versioned) > | build-deps handling to: > | > | "pick the first package version satisfying the given relation which is > | also *available*" > | > | Otherwise, we might pick OR'ed build-dependency which is unavailable, > | and ditch alternative(s) which are actually available. > | > | Actually do what we have been asked for. If anyone finds any design > | flaw with that, please let me know ;-) That is also fairly trivial to > | implement, the hard part is the sound design. > > AFAIK, sbuild will just pick the first one in the list, whether it's > available or not. There is some value in using the same algorithm as > sbuild.
Fair concern. Well, I guess we can have both algorithms called via two different options: the one that just spits package names, and the one that also check their availability. I really intend to use the second one. and I have it implemented now against master, though it is not that much tested (ORed build- deps included). I'll have a look to add the simpler case too. > | > I think this is fine. It solves 95% of the cases people are interested > | > in. > | > | If we can have 100% on board, why not just have it. I guess I just need > | to sit down and add code to address OR'ed build-deps > | (will do that, this weekend, eventually) > > Because you add overhead for everybody if you start loading the package > lists for each invocation of dpkg-checkbuilddeps. This isn't so much of > a problem on amd64 and other fast arches as it is on slow arches like > mipsel or avr32. Ahem. Two different options might serve that too. We only add that overhead if it is actually called. Sounds good? -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
