On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote: > On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote: > > 3.1) Provide an easy and reliable way to tell if the optional targets > > are implemented. > > And once that's there, clarify Policy to say what dpkg-buildpackage et al > will do: if optional targets are missing, do the old thing. If the optional > targets are there, do the new thing instead.
... so that buildd will rely on dpkg-buildpackage behaviour documented by policy. OK for me. > > The first is to add a debian/rules.version with meaning: > > debian/rules.version is present and is "1\n": build-arch and build-indep > > are implemented > > > > The second is to add a debian/rules.targets with the list of available > > optional targets. > > > > First solution is easier to implement. Second one scale better but does > > not allow to revoke the meaning of a target. > > Well, regardless of whether we pick versions or listing available targets, > why not do it with a new control file field in the source section? > That seems logical, and avoids creating a new file. > > It's tangentially relevant that the .dsc and .changes files include a Format > field that is a version number. Having a "Rules-Format: 2" field in control > seems okay to me. Some packages generate the control file at build time (e.g. from a control.in). We need to access the file before debian/rules is used, and debian/control might not exist yet. Cheers, Bill.
