On Sun, Nov 04, 2007 at 07:41:21PM +0000, Ian Jackson wrote: > > > The package should declare (eg with > > > Build-Options) what the situation is. > > > > My patch does that. > > Ah, yes. > > Bill, can you give me a reference to what you consider the definitive > definition of the behaviour of your proposed patch ? Presumably this > would be in the form of a policy amendment ?
After those four years, I am bit lost myself. This is what I wrote at the time: + <sect1 id="f-Build-Options"> + <heading><tt>Build-Options</tt></heading> + <p> + The syntax is a list of options separated by + commas that are implemented in the build process. + The following options are defined: + <list> + <item> <tt>build-arch</tt> The optional targets "build-arch" + and "build-indep" are implemented by <tt>debian/rules</tt> + as defined in <ref id="debianrules">. </item> + </list> + </p> + </sect1> Some comments: 1) The target binary-arch and binary-indep are already mandatory according to debian-policy. No need to mention them. 2) Build-Options should ideally use the same separator/line breaking rule as Depends (packages name being replaced by options). I will let you fill the specific. My patch only implement commas separation, but since only build-arch is implemented, this is not a practical issue. This option signals a property of the source package, but not the associated behaviour of dpkg-buildpackage. Obviously a patch to dpkg-buildpackage should document that. This is my first try: 1) Unreckognized Build-Options are ignored by dpkg. 2) The following option is reckognized: build-arch: If this option is set, dpkg-buildpackage, when invoked with the -B option, will call 'debian/rules build-arch' instead of 'debian/rules build'. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
