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

Re: dpkg-checkbuilddeps to generate a frontend friendly package list



On Fri, 04 Dec 2009, George Danchev wrote:
> 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

I did not respond to that part. IMO dpkg-checkbuilddeps should not try to
provide features that concerns the upper layer. We already have apt-get
build-deps for the intelligent handling of build dependencies, however
dpkg-checkbuilddeps is not user-friendly currently due to the fact that
it's not easy to install the missing build-dependency by simple cut &
pasting of the list due to the version relation cluttering the output.

So changes I'd like:
- more user-friendly with a cut & pastable list after "apt-get install"
- more machine-friendly with a formatted output on request (details to be
  defined, probably something like: plain fields, missing/conflicting
  packages only with/without relation)

Cheers,
-- 
Raphaël Hertzog


Reply to: