Re: dpkg-checkbuilddeps to generate a frontend friendly package list
> ]] George Danchev
Sorry for being so late.
> | It adds -f option which tries to prepare such a list via facilities
> | provided by AptPkg. List comes to STDOUT, while warnings to STDERR, so
> | users can filter these as well. Build-Conflicts are added as package-.
>
> A minor thing, I'd rather just have this enabled by default. The build
> is going to fail anyway, so spitting out three extra lines isn't a big
> deal.
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.
> | The problem here is that frontends only handle '=' relation, at best,
> | so we can only pass them package=version regardless of whether user
> | supplied >>, <<,
> |
> | >=, <= or = in their Build-Depends and Build-Coflicts line from
> | >debian/control.
> |
> | That -f option does not try to be very smart, and after verifying that
> | Build- Depends/Conflicts could be satisfied it leaves the package
> | version selection to the frontend based on its current settings.
>
> 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)
> | 1) Would you accept patches like that, based on AptPkg, i.e. is it too
> | intrusive for you? I can see your reasons if you prefer to avoid the
> | extra dependency on libapt-pkg-perl.
>
> Other people have written about how to make this optional, and
> particularly if this is just used in --minimal-versions-only-please
> mode, I don't see the problem.
>
> I don't have commit rights, and I haven't looked at your patch yet, but
> as an idea on how to approach this, it sounds good.
Actually we don't need commit rights; if we end up with something useful they
will eventually accept it.
> | 2) Introduce a separate tool in a separate source/binary package which
> | could then depends on whatever is needed.
>
> If so, there's misc stuff in pbuilder which does this already. I'd
> rather have dpkg-checkbuilddeps spit out and apt-gettable line.
That stuff is trying to install a dummy package with build-depends listed as
depens. That is fine for chroots, by I don't want my main system to track such
dummy packages ;-) Actually I don't want to install anything, but to spit a
sensible list of requested build-depens and -conflits.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: