Bug#432564: Allow debian/rules to not be a makefile

[Steve Langasek]

On Thu, Dec 06, 2007 at 10:05:46PM +0100, Bill Allombert wrote:
> On Thu, Dec 06, 2007 at 06:31:50PM +0100, Loïc Minier wrote:
> >  So arguing that you can pretend that your rules are a makefile while
> >  they are actually not is completely destroying the only benefit of the
> >  requirement...

> Personnaly I would not mind if Debian policy mandated that
> 1) debian/rules should be a Makefile

> 2) Nothing (including the Debian policy itself) should assumes it is 
> a Makefile or has any property expected of a Makefile.

IOW: you'd be fine with a policy requirement that is totally useless and
isn't enforced in practice?

What would be the point of that?  I advocate requiring debian/rules to be a
makefile so that we *can* depend on make behavior.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Bill Allombert]

On Thu, Dec 06, 2007 at 06:31:50PM +0100, Loïc Minier wrote:
>  So arguing that you can pretend that your rules are a makefile while
>  they are actually not is completely destroying the only benefit of the
>  requirement...

Personnaly I would not mind if Debian policy mandated that
1) debian/rules should be a Makefile

2) Nothing (including the Debian policy itself) should assumes it is 
a Makefile or has any property expected of a Makefile.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

Bug#432564: Allow debian/rules to not be a makefile

[Loïc Minier]

On Fri, Dec 07, 2007, Anthony Towns wrote:
> >  Except it completely breaks any hope to benefit of this new Policy
> >  requirement:
> Uh, this isn't a new policy requirement. It's been a MUST in policy for
> years before you even applied to be a DD, eg.

 Right; please strike "new" in my sentence; the "new" part is to
 actually rely on that.

-- 
Loïc Minier

Bug#432564: Allow debian/rules to not be a makefile

[Anthony Towns]

On Thu, Dec 06, 2007 at 06:31:50PM +0100, Lo?c Minier wrote:
> On Thu, Dec 06, 2007, Anthony Towns wrote:
> > > Regardless, even requiring debian/rules to be a makefile doesn't
> > > actually do much, because someone could do something like: 
> > > .DEFAULT: 
> > > debian/irule $@
> > > or whatever.
> > > People should be using make, but if they have a valid reason for doing
> > > something else, policy shouldn't get in the way.
> > And policy doesn't get in their way, because they can just do the above...
>  Except it completely breaks any hope to benefit of this new Policy
>  requirement:

Uh, this isn't a new policy requirement. It's been a MUST in policy for
years before you even applied to be a DD, eg.

>  - passing -j2 might not be honored (Policy doesn't require it anyway)
>  - querying the list of targets (to check for build-arch for example)
>with a make flag wont work either (Policy doesn't require it anyway)

That's true -- but at least by specifically hacking your way out of
make land by something like the above, it's clear that it's your job to
make those features work. It'll partially honour those things too, eg
"make -j2 binary-indep binary-all" will run both targets at once.

As opposed to writing debian/rules as a #!/bin/sh script and then
wondering why people are invoking it with weird flags, multiple targets,
or variables as parameters instead of in the environment.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#432564: Allow debian/rules to not be a makefile

[Loïc Minier]

On Thu, Dec 06, 2007, Anthony Towns wrote:
> > Regardless, even requiring debian/rules to be a makefile doesn't
> > actually do much, because someone could do something like: 
> > .DEFAULT: 
> >   debian/irule $@
> > or whatever.
> 
> > People should be using make, but if they have a valid reason for doing
> > something else, policy shouldn't get in the way.
> 
> And policy doesn't get in their way, because they can just do the above...

 Except it completely breaks any hope to benefit of this new Policy
 requirement:
 - passing -j2 might not be honored (Policy doesn't require it anyway)
 - querying the list of targets (to check for build-arch for example)
   with a make flag wont work either (Policy doesn't require it anyway)

 So arguing that you can pretend that your rules are a makefile while
 they are actually not is completely destroying the only benefit of the
 requirement...

-- 
Loïc Minier

Bug#432564: Allow debian/rules to not be a makefile

[Anthony Towns]

On Tue, Jul 10, 2007 at 01:42:03PM -0700, Don Armstrong wrote:
> On Tue, 10 Jul 2007, Russ Allbery wrote:
> > I also could have sworn that we recently tightened this requirement,
> > but I can find no mention of that in changelog with some quick
> > searches. Am I just imagining things?
> It was tightened about 2 or 3 years ago, iirc.

See the previous policy bugs for this issue, 88111 and 148941:

 > It'll have happened during Manoj's incorporation of the packaging-manual
 > into policy. See 72949. You'll notice you seconded it... :)

-- http://lists.debian.org/debian-policy/2001/03/msg00020.html 

While they might seem old enough to have been lost in history, they were
only actually closed in April last year...

> Regardless, even requiring debian/rules to be a makefile doesn't
> actually do much, because someone could do something like: 
> .DEFAULT: 
> debian/irule $@
> or whatever.

> People should be using make, but if they have a valid reason for doing
> something else, policy shouldn't get in the way.

And policy doesn't get in their way, because they can just do the above...

Benefits of using a makefile include (as discussed in the previous
bug reports),

 > Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage.

 > 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

It looks like there was more in the thread than the bug log.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#432564: Allow debian/rules to not be a makefile

[Jon Dowland]

On Tue, Jul 10, 2007 at 04:30:00PM +0100, Ian Jackson wrote:
>   debian/rules must be an executable script with an
>   appropriate #!  line (so, if it is a makefile it must
>   start with the line #!/usr/bin/make -f) so that it can
>   be invoked by saying its name.  It should use a
>   widely-used language, and should restrict itself to
>   features portable even to older versions of its
>   interpreter.

Without weighing in with my opinion on whether or not this
should be changed, I suggest the proposed change limits the
scope of potential interpreters to those Essential: yes or
which are depended on by build-essential.

I haven't thought of a clear way of wording this, though.


-- 
Jon Dowland



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Don Armstrong]

On Tue, 17 Jul 2007, Manoj Srivastava wrote:
> On Tue, 10 Jul 2007 13:42:03 -0700, Don Armstrong <[EMAIL PROTECTED]> said: 
> > Regardless, even requiring debian/rules to be a makefile doesn't
> > actually do much, because someone could do something like:
> 
> > .DEFAULT:
> >   debian/irule $@
> 
> > or whatever.
> 
> I actually see this as a argument for not changing the rule,
> since using a Makefile does not in any way add restrictions for the
> developer.  debian/rules has been a makefile forever, allowing it to be
> anything else doesn't buy anything practical, just a little geek value
> for useless packages like shoop.

I don't have a problem with requiring that debian/rules be a makefile;
what I'm concerned about are any assumptions about what debian/rules
actually contains besides it being a valid makefile.


Don Armstrong

-- 
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
 -- W. Churchill

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Manoj Srivastava]

On Tue, 10 Jul 2007 13:42:03 -0700, Don Armstrong <[EMAIL PROTECTED]> said: 

> Regardless, even requiring debian/rules to be a makefile doesn't
> actually do much, because someone could do something like:

> .DEFAULT:
> debian/irule $@

> or whatever.

I actually see this as a argument for not changing the rule,
 since using a Makefile does not in any way add restrictions for the
 developer.  debian/rules has been a makefile forever, allowing it to be
 anything else doesn't buy anything practical, just a little geek value
 for useless packages like shoop.

Saying that the ./debian/rules files is a Makefile is not
 stating what language that rules have to be written in, since the
 actual rules can be in any language whatsoever, and indeed, debhelper
 is an example of how tools can still intercede  in the build process,
 and hide some of the complexities from the user (cf. the one line cdbs
 rules makefile). But stating it is a makefile adds in all kinds of
 affiliated baggage that the developer can then depend on; for example,
 the semantics of:
   "make -f ./debian/rules -j0 clean build binary" is another example of 
 are clear.

 There's nothing you can do with a non-makefile executable that you
 can't just as easily do by invoking that executable from the makefile,
 and this other executable will never be able to emulate all of make's
 behaviour.

I think I must object to this, on the grounds that we are now
 changing an published interface to the package building process.
 Indeed, I have used makefiles that include ./debian/rules and derive
 targets and tweak the make rules in the debian/rules process
 (security related experiments), and I would strongly object to the
 mechanisms being yanked out from under me. make -n -p -d also allows a
 level of debugging detail that is  not readily available otherwise.


If there is a technical reason (apart from, ooh, I hate make)
 for allowing ./debian/rules not to be a makefile, I'll be happy to
 listen. What exactly is being prevented from having ./debian/rules a
 Makefile? 

manoj
-- 
You recoil from the crude; you tend naturally toward the exquisite.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Russ Allbery]

Please remember to send discussion of Policy proposals to the relevant bug
instead of only to the debian-policy list.  Discussion not sent to the bug
is much harder to track down later when one tries to figure out the
history of a Policy change.

Otavio Salvador <[EMAIL PROTECTED]> writes:
> Gunnar Wolf <[EMAIL PROTECTED]> writes:
>> Otavio Salvador dijo [Tue, Jul 10, 2007 at 05:53:56PM -0300]:

>>> While I agree with you that majority of people might do bad code I
>>> also think that some very complicated packages (OO, X, Kernel and
>>> like) can use it and make maintainers life easier.

>> Maybe we should keep a recommendation for people to write makefiles,
>> for ease of maintainability - but we should not keep it as a
>> requeriment.

> Yes, I agree on that :-)

If we're going to remove this requirement, I'd like to get an opinion from
the security team and ideally from the release managers first, since I
think much of the burden of dealing with non-Makefile debian/rules is
going to fall on them.

My understanding of the previous opinions of those two teams was that they
wanted to see fewer different build systems in Debian, so this is somewhat
going against the grain of their desires.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Russ Allbery]

Don Armstrong <[EMAIL PROTECTED]> writes:

> It was tightened about 2 or 3 years ago, iirc.

> Regardless, even requiring debian/rules to be a makefile doesn't
> actually do much, because someone could do something like: 

> .DEFAULT: 
> debian/irule $@

> or whatever.

> People should be using make, but if they have a valid reason for doing
> something else, policy shouldn't get in the way.

I suppose that's true.

Okay, we can at least explore the option of double-checking that Policy
specifies everything that we're assuming make will do and that the rest of
the project assumes.  Does the current Policy text have enough details
(with a strong enough requirement) around arguments, exit status, and so
forth that something written exactly to Policy would behave like a
makefile to every other part of the project?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Don Armstrong]

On Tue, 10 Jul 2007, Russ Allbery wrote:
> I also could have sworn that we recently tightened this requirement,
> but I can find no mention of that in changelog with some quick
> searches. Am I just imagining things?

It was tightened about 2 or 3 years ago, iirc.

Regardless, even requiring debian/rules to be a makefile doesn't
actually do much, because someone could do something like: 

.DEFAULT: 
  debian/irule $@

or whatever.

People should be using make, but if they have a valid reason for doing
something else, policy shouldn't get in the way.


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Andreas Barth]

* Ian Jackson ([EMAIL PROTECTED]) [070710 18:05]:
>   4.9 Main building script: debian/rules
> 
>   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.
> 
>   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.

> There is no technical reason why this has to be a makefile.  I propose:

What is the use case of the change? I already see enough "bad code"
right now, and it would only get worse if people start to write their
make file in lets say ruby.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Russ Allbery]

I see no benefit in changing this, which I think is the strongest argument
against doing so given that it's been an RC bug to have a non-makefile
debian/rules for both sarge and etch.

The advantage of the current rule is that we can make certain basic
assumptions that we would only otherwise be able to make if the people
writing non-makefile debian/rules files were quite skilled.  I'm dubious
that this will be the case.  It also helps in modifying other people's
packages (which I know can be difficult for other reasons, but at least
I have a head start when I can assume make).

I also could have sworn that we recently tightened this requirement, but I
can find no mention of that in changelog with some quick searches.  Am I
just imagining things?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Gunnar Wolf]

Ian Jackson dijo [Tue, Jul 10, 2007 at 04:30:00PM +0100]:
> Package: debian-policy
> Version: 3.7.2.2
> 
> Currently, we have:
> 
>   4.9 Main building script: debian/rules
> 
>   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.
> 
>   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.
> 
> There is no technical reason why this has to be a makefile.  I propose:
> 
>   4.9 Main building script: debian/rules
> 
>   This file is normally an executable makefile, and contains the
>   package-specific recipes for compiling the package and building
>   binary package(s) from the source.
> 
>   debian/rules must be an executable script with an appropriate #!
>   line (so, if it is a makefile it must start with the line
>   #!/usr/bin/make -f) so that it can be invoked by saying its name.
>   It should use a widely-used language, and should restrict itself to
>   features portable even to older versions of its interpreter.

I completely second this. It makes sense, and has been the subject of
too many sterile discussions. 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgplVKZomW3RN.pgp
Description: PGP signature

Bug#432564: Allow debian/rules to not be a makefile

[Ian Jackson]

Package: debian-policy
Version: 3.7.2.2

Currently, we have:

  4.9 Main building script: debian/rules

  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.

  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.

There is no technical reason why this has to be a makefile.  I propose:

  4.9 Main building script: debian/rules

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

  debian/rules must be an executable script with an appropriate #!
  line (so, if it is a makefile it must start with the line
  #!/usr/bin/make -f) so that it can be invoked by saying its name.
  It should use a widely-used language, and should restrict itself to
  features portable even to older versions of its interpreter.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]