Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
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.
Reply to: