> Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
> >
> > Debian Policy 4.9 says about debian/rules:
> >
> > "It must start with the line #!/usr/bin/make -f, so that it can be  
> > invoked by saying its name rather than invoking make explicitly."
> 
> Dear all,
> 
> I also do not understand that rule. There are a larger number of packages that
> are simply removing all the content from the make file, for instance like:
> 

[...]

I don't think there's a point in disussing whether or not the shebang-line must
be there (and that it must read as stated in policy). The fundamental point is
that debian/rules must be a Makefile (and not just looks like a Makefile).
Debian Policy 4.9 guarantees that the behavior of debian/rules will be the same
if called as either make -f debian/rules or simply debian/rules.

> 
> I think that the key part of the Policy is the interface: debian/rules can be
> called with arguments such as ‘build’, ‘clean’, etc. When unique features of
> GNU Make are not needed, I do not see much advantage in requiring that the
> parts that actually do the work are wrapped into a makefile. Can’t we just
> trust the maintainers instead of putting restrictions that in the end are only
> increasing complexity for no benefit? 
> 

[...]

Yes, it's the interface. And the first sentence of 4.9 reads as:

"This file must be an executable makefile, and contains the package-specific
recipes for compiling the package and building binary package(s) from the
source."

This implies that the interface is to a larger extent documented in the make
documentation. Policy also specifies that a set of targets must be supported by
this makefile, but it doesn't say that these are the (only) supported arguments.
What about -j, for example? Not part of 4.9, but supported and documented by
make.

Adhering to a standard actually decreases complexity. What may seem "elegant" at
first makes it a lot harder for other people to step in. For example, the
VDR-solution IMHO doesn't decrease complexity, it merely hides it.

Best,
Michael

Attachment: pgp7d7EB6nuxy.pgp
Description: PGP signature

Reply via email to