[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. 

IMO if we are talking about build-deps availability or installability, 
regardless of whether how the package list to be supplied looks like, we are 
already there (at the upper level), because most likely it is the upper level 
who will transport and feed the build-deps in question to the lower level. So, 
if we are already there, it would make sense, to explore it on demand. Hence, 
I beg to differ (though I see no one currently supports my view), and defend 
that baldly, but not to an extend of becoming boring of course.

> 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.

Yes, that is visible.

> So changes I'd like:
> - more user-friendly with a cut & pastable list after "apt-get install"

Filtering out an apt-gettable package list is a matter or a simple regex I 
already provided in my patch, and I know you are perfectly able to add such a 
'best effort' package list support.

> - 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)

That might need further specification, so I can't comment on it.

pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

Reply to: