Re: dpkg-checkbuilddeps to generate a frontend friendly package list
]] George Danchev
| 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
| 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
| 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
| 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.
| 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.
| 3) Rewrite that with calls to `apt-cache policy' (to get available
| package versions) and `dpkg --compare-versions' (for version
| comparisons), which is not a sign of great engineering ;-)
Let's not try to parse our own output. :-)
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are