Le Sat, Oct 31, 2009 at 01:01:57AM -0500, Manoj Srivastava a écrit :
>
> The clarification has already been offered, and has one second:
>
> --8<---------------cut here---------------start------------->8---
> --- policy.sgml 2009-10-21 20:49:37 +0000
> +++ policy.sgml 2009-10-31 01:10:42 +0000
> @@ -1725,7 +1725,10 @@
> <p>
> It must start with the line <tt>#!/usr/bin/make -f</tt>,
> so that it can be invoked by saying its name rather than
> - invoking <prgn>make</prgn> explicitly.
> + invoking <prgn>make</prgn> explicitly. That is, invoking
> + either of <tt>make -f debian/rules <em>args...</em></tt>
> + or <tt>./debian/rules <em>args...</em></tt> must cause
> + identical behaviour in each case.
> </p>
>
> <p>
> --8<---------------cut here---------------end--------------->8---
>
> Rationale: Since debian/rules must be a makefile, and policy has
> already specified that the interpreter the fle should be called with s
> make (it even specifies that the #! line), it follows that how the file
> is invoked should not change the behaviour of the build system.
>
> The clarifying language above was proposed by Ben Finney, and
> has been seconded by Manoj Srivastava.
First of all, I would like to remind that seconding is not a vote, but a
statement that consensus was reached. In my opinion, it is prematurate to
declare consensus.
In my understanding of the Policy, the reason why it is specified that
debian/rules must start by ‘#!/usr/bin/make -f’ is to ensure the possibility to
call debian/rules directly (not by make -f debian/rules). Indeed, this is the
way the key components of our system are using to build binary packages.
§4.9 contains:
‘It [debian/rules] must start with the line #!/usr/bin/make -f, so that it can
be invoked by saying its name rather than invoking make explicitly.’
This specification uses ‘rather than’, not ‘as well as’, which suggests that
the preferred way to run the rules file is to call ‘debian/rules’ and not ‘make
-f debian/rules’. Therefore I do not see the need to make extrapolations (the
equivalence between the two commands) part of the Policy.
The proposed patch puts additional constraints on the packages, that would make
more difficult refactor later the Policy towards make a clearer abstraction of
the build interface (which I think is desirable), by for instance speficying
that debian/rules is an executable program that must accept clean, binary,
binary-arch, binary-indep, and build as parameters and honor the options passed
by the DEB_BUILD_OPTIONS environment variable, and leave the implementation up
to the maintainer. (Another example, with which I disagree, would be to
completely deprecate debian/rules and specify that our packages must be built
by dpkg-buildpackage, but we must acknowledge that this is an open issue as
well).
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to
debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact
listmaster@...
signature.asc (205 bytes) 