[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg-checkbuilddeps to generate a frontend friendly package list

(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 

Here is my first attempt to address such a feature (against the version found 
in sid 15.5.3):


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.

Reply to: