Re: dpkg-checkbuilddeps to generate a frontend friendly package list
> ]] 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>
Reply to: