Bug#88111: policy should not dictate implementation details
On Thu, Mar 01, 2001 at 05:43:28PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > Right. Give a policy diff which specifies *exactly* what interfaces
> > are required of debian/rules.
>
> I'll make some other changes as well. I notice the current policy
> documented is poluted with things like scripting advise, which
> should be in a seperate document.
Agreed (and I've already written to -policy about this about 2 weeks
ago).
> Patch is attached.
> - <sect1>
> - <heading>Error trapping in makefiles</heading>
Agreed, as long as it goes somewhere.
> - <sect1>
> - <heading>Obsolete constructs and libraries</heading>
Ditto.
> <p>
> - This file must be an executable makefile, and contains the
> + This file must be an executable, and contains the
> package-specific recipes for compiling the package and
> building binary package(s) out of the source.
> </p>
>
> <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.
> + The <tt>debian/rules</tt> takes a single argument, which is
> + the target we want to build. Success should be indicated
> + using the exitcode: an exitcode of 0 indicates success,
> + any other code indicates a failure.
Simply not true. Read the source code for dpkg-buildpackage. I'm
objecting to this until we specify the following (growing) minimal
interface:
debian/rules [variable=value ...] target [variable=value ...]
exit: 0 if OK, non-0 otherwise
debian/rules -q target
exit: 2 if target cannot be built (doesn't exist), non-2 otherwise
> <p>
> - For some packages, notably ones where the same
> - source tree is compiled in different ways to produce
> - two binary packages, the <prgn>build</prgn> target
> - does not make much sense. For these packages it is
> - good enough to provide two (or more) targets
> - (<tt>build-a</tt> and <tt>build-b</tt> or whatever)
> - for each of the ways of building the package, and a
> - <prgn>build</prgn> target that does nothing. The
> - <prgn>binary</prgn> target will have to build the
> - package in each of the possible ways and make the
> - binary package out of each.
> - </p>
Not so obvious; we've already specified what the build target must
do.
> - <p>
> - The <prgn>build</prgn> target may need to run
> - <prgn>clean</prgn> first - see below.
> - </p>
Agreed.
> - <p>
> - When a package has a configuration routine that
> - takes a long time, or when the makefiles are poorly
> - designed, or when <prgn>build</prgn> needs to run
> - <prgn>clean</prgn> first, it is a good idea to
> - <tt>touch build</tt> when the build process is
> - complete. This will ensure that if <tt>debian/rules
> - build</tt> is run again it will not rebuild the
> - whole program.
> - </p>
Ditto.
> - <tag><tt>get-orig-source</tt> (optional)</tag>
> + <p>
> + The optional target are:
> + <taglist>
> + <tag><tt>get-orig-source</tt></tag>
> <item>
Good cosmetic change. Does anyone provide this target, incidentally?
> - <p>
> - This target is optional, but providing it if
> - possible is a good idea.
> - </p>
Agreed.
> <p>
> - The <prgn>build</prgn>, <prgn>binary</prgn> and
> - <prgn>clean</prgn> targets must be invoked with a current
> + <tt>debian/rules</tt> must be invoked with a current
> directory of the package's top-level directory.
> </p>
Perhaps better: debian/rules must assume that it is being invoked ...
We're not actually invoking it in policy.
> - This is generated by the <prgn>822-date</prgn>
> - program.
> + This can generated by the <prgn>822-date</prgn>
> + program, or by using the -R option for date.
Yes.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: