Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Le Mon, Feb 09, 2009 at 09:30:48AM +0100, Fabian Greffrath a écrit :
> Dear -devel,
>
> I'd like to suggest the introduction of two new control fields to the
> source stanza of debian/control, namely Build-Recommends and
> Build-Suggests.
Dear Fabian,
this is a very intersting proposal that would address perfectly the issues I
had with running regression tests with Perl modules. Let's imagine possible
consequences (in the case of Perl modules) of unavailability of a package in
one of the three Build- fields:
- Binary packages would be impossible to prepare if Build-Depends are not
completely satisfied.
- Regression tests would miss some information if Build-Recommends are
missing, but building would not fail and the binary package would be
identical, i.e., the only diffrerence would be the logs. Advantage: a package
does not become instantaneously unbuildable if one of its Build-Recommends is
unavailable for whatever reason.
- Regression tests would get additional information if Build-Suggests are
present. Typically, Build-Suggests could be used with contrib or non-free
packages. Here is a real life example: the bioperl-run package provides
wrappers for many programs and regression tests for all the wrappers; most
programs are packaged, and would go to to Build-Recommends, but some (clustalw,
phylip) are non-free, and would go in Build-Suggests. Bioperl-run's regression
tests do not fail if the wrapped programs are not found.
This said, there are insightful comments in this thread that underline what
should not be done with Build-Recommends in the context of packages that need
compilation, so the need for the two new fields, althoug appalling, is probably
not pressing. I guess that if you manage to convince the dpkg and sbuild
maintainers to implement them, you will have more chances to get the fields
accepted ;)
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: