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 :) Agreed. 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpTLFJu6ySBv.pgp
Description: PGP signature