Hello,
(I'm not subscribed to the list, so please CC)
From time to time people ask (myself included) about frontend friendly list
generated by dpkg-checkbuilddeps so that they can pass it to their favorite
frontend like apt, aptitude, or cupt to install/remove build-depends and
build-conflicts.
Here is my first attempt to address such a feature (against the version found
in sid 15.5.3):
http://people.debian.org/~danchev/tmp/
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-.
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.
However, I imagine that we have another (separate) class of users which want
to enforce a stricter list to the frontend (which would add a certain amount
of noise to the outputted list), so it is doable to add another separate
option which picks a smarter selection of package=version according to the
relations supplied in control file. For, instance if we have in debian/control:
Build-Depends: foo (>= 1.2.3-4)
it then searches for the newest version possible within {VersionList} in
AptPkg terms and supplies foo=newest_version
or (not that interesting case, but possible)
Build-Depends: foo (<= 1.2.3-4)
it then searches for the newest version possible which is less than or equal
to 1.2.3-4 and supplies foo=that_version
So, my list of questions or routes possible being:
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.
2) Introduce a separate tool in a separate source/binary package which could
then depends on whatever is needed.
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 ;-)
4) Leave that to the Almighty sbuild tool?
5) Deal with that in the frontends themselves?
6) Do nothing ;-)
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part.