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

Re: Introducing Build-Recommends / Build-Core-Depends?

On Sat, 13 Aug 2011 11:44:46 +0000 (UTC)
Sune Vuorela <nospam@vuorela.dk> wrote:

> On 2011-08-13, Andreas Barth <aba@not.so.argh.org> wrote:
> > Introducing Build-Recommends / Build-Core-Depends
> I like making it easier to bootstrap new architectures, but I don't like
> overloading the 'recommends' word with a partly different meaning.

It's not 'that' different. Recommends currently means that the majority
of installations would be expected to need it. Build-Recommends means
that the majority of builds would be expected to need it.

Personally, I'm not sure if Build-Core-Depends is better but there does
need to be a way to list particular build-dependencies as imperative
and configurable, usually along the lines of what the
upstream ./configure type script can disable.

> (And since this is my biggest issue with this proposal, I think it is
> very good :)


I think the idea can be extended. There isn't much point in *only*
listing those packages which are directly involved in bootstrapping
cycles today, this would only cause repeated cycling through the
packages as the packages update their functional support. It would be
useful for this proposal to be adopted by many, many packages on the
basis of what can be disabled (with judicious use of the debhelper -N
option and changes in debian/rules to the ./configure or equivalent
support) as a form of future proofing.

If your (typically library) package *can* have functionality disabled,
it should be possible to use this support to build the package that way
for bootstrapping purposes, whether or not anyone is aware of a problem
in advance.


Neil Williams

Attachment: pgpfV7Ju3lJyd.pgp
Description: PGP signature

Reply to: