On ke, 2007-12-05 at 21:11 +0100, Matthias Klose wrote:
> IIRC we cannot assume that debian/rules is a makefile and pass them as
> macros directly, so we have to pass them as environment variables.

Debian Policy, 4.9, "Main building script: debian/rules":

This file must be an executable makefile

So I think we can assume things.

Since I happened to have the etch/main sources lying around unpacked on
a hard disk (don't ask), I ran a quick scan for the first lines of
debian/rules files:

1 #! /bin/sh
1 #!/bin/sh -e
1 #!/usr/bin/make -ef
403 #! /usr/bin/make -f
13 #! /usr/bin/make -f
1 #!/usr/bin/make -f
9876 #!/usr/bin/make -f
17 #!/usr/bin/make -f
1 #!/usr/bin/make -f
4 #!/usr/bin/make -f
2 #!/usr/bin/make -f
1 #! /usr/bin/make -rf

That's two packages that use /bin/sh, everything else uses make.

The two packages in question are leave and webserver-package, and as it
turns out, the latter is a false positive, since my grepping for
debian/rules found a file that wasn't a real debian/rules file. So, only
one package in etch/main uses something not a makefile for debian/rules.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007 at 08:15:08AM +0000, Frank Küster wrote:
> Indeed - but there's a bug, #432564, requesting to change it.

Hmm. Which seems quiet controversal. Maybe the DD should find a decision
on this, before anything else? But this topic is again an example why
changing debian/rules to something different then a makefile could be
bad.

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> a) Adds no practical value

It's about rejecting a change to policy; I don't see why it should add
practical value.

> b) does not represent current practice
> c) not implementing the proposal is not a technical hindrance to any
> package

This is the same point. Just for the record, there's a small set of
packages not based on a Makefile for debian/rules.

> d) stands in the way of technical proposals like passing information
> to the build system on the command line
> e) prevents people from relying on make semantics for builds.

The two above points are the same argument. The only proposal I know
it stands on the way of is the one to list implemented targets with a
special make invocation which seemed flaky anyway.

> The only reason for the bug report seems to be
> a) because we can
> b) aesthetics
> c) profit???

Not constraining the interface if we don't need to? There's a huge
difference in possibilities between "any script" and "a Makefile".

Yes, we can do it in other ways, such as defining which flags or env
vars have to be honored, or which files have to be read.

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007, Manoj Srivastava wrote:

> >> d) stands in the way of technical proposals like passing information
> >> to the build system on the command line
> >> e) prevents people from relying on make semantics for builds.
>
> > The two above points are the same argument. The only proposal I know
> > it stands on the way of is the one to list implemented targets with a
> > special make invocation which seemed flaky anyway.
>
> [...] unimportant, if indeed it works.

I got the feeling it was flaky from the criticism I read on
debian-policy@ and that it couldn't work for all Makefiles; for example
someone proposed to "make -f debian/rules -pn | grep '^build-arch:'"
but this obviously wont fly if this is implemented as a "build-%:"
rule.
In fact I have packages with build-% rules, and certainly they
shouldn't match such checks as they don't implement build-arch.

> > Not constraining the interface if we don't need to? There's a huge
> > difference in possibilities between "any script" and "a Makefile".
> I do not agree that there is no need to so constrain it. I have
> made the argumen in #88111; please read it.

I did; I don't think you can reliably include a Makefile written by
somebody else with the only constraints of the current policy. It
would require tons of policies to make this reliable.

Process interfaces draw a much clearer line. I'm sure that as the make
maintainer you do know how complex a Makefile can get. It seems much
more easy to usefully standardize the behavior of a process (flags /
arguments, exit code, env vars, external deps, current working
directory: sounds sane) than of a Makefile.

> > Yes, we can do it in other ways, such as defining which flags or env
> > vars have to be honored, or which files have to be read.
> Right. We can re-invent the wheel on our own, in a classic
> example of NIH, for absolutely no reason -- apart from not liking a
> solution that is already in place.

I disagree that it's for no reason; some proposed uses aren't safe and
we have better replacement proposals (such as using a control field or
an env var).
We already proved the use over many more years of env vars passed to
debian/rules, arguments passed on the command-line, or of data in
debian/control. Proposing to use the new channels such as makefile
inclusion or querying for the implemented rules is looking for trouble
and discourages other options.


I'm not under the impression that you're still open-minded on the
topic, and since you're one of our beloved policy maintainers, and make
maintainer, I don't think it's worth our time to repeat the arguments
which have already been made.
I simply want it recorded that some people do think it's a bad idea
to require debian/rules to be a Makefile; I hope it will discourages
people to rely on this.

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> *Sigh*.
> __> make -pn build-arch | grep '^build-arch'
> build-arch:
> OK?

Dude, there's no need to sigh out loudly; "make -pn $target" doesn't
change anything, but you didn't even read the rest of my point: that
packages were *already* using build-% and that this was not a proper
test to see whether a package is implementing build-arch...

It's really saddening to not even be read but to get a condescending
reply.

> > > Yes, we can do it in other ways, such as defining which flags or env
> > > vars have to be honored, or which files have to be read.
> > Right. We can re-invent the wheel on our own, in a classic
> > example of NIH, for absolutely no reason -- apart from not liking a
> > solution that is already in place.
>
> > We already proved the use over many more years of env vars passed to
> > debian/rules, arguments passed on the command-line, or of data in
> > debian/control. Proposing to use the new channels such as makefile
> > inclusion or querying for the implemented rules is looking for trouble
> > and discourages other options.
>
> What new channel? This channel (./debian/rules as a Makfile)
> has been in practice since around 1996, and in policy as a mUST since
> 2001 (which was, I think, before you became a DD).

(Condescending again.) The new channels are "makefile inclusion" and
"querying for implemented rules". Requiring that my debian/rules be
include-able in any other Makefile or that you can query my
debian/rules for some specific targets sets constraints which have not
been required before, even if it was required that debian/rules be "a
makefile".

> If you think it is new, you must not really have read policy
> very well.

The "new *channels*".

> > I'm not under the impression that you're still open-minded on the
> > topic, and since you're one of our beloved policy maintainers, and make
> > maintainer, I don't think it's worth our time to repeat the arguments
> > which have already been made.
>
> Ah. Argumentum ad Hominem. "I can't refute Manoj's arguments, so
> let us paint him as an irrational bigot". I am going to ignore this as
> the logical fallacy that it is.

I didn't say you were irrational; still your response vastly proves my
point: that you're not reading in a mindset where you could reconsider
your position.

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007, Russ Allbery wrote:
> I think we need a clear consensus to change
> it, and I haven't gotten the impression that such a consensus exists.

(Fair enough.)

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Dec 06, 2007, Steve Langasek wrote:
> Then why in the world are you using "build-%" if you don't support
> build-arch? What other values of '%' are you using?

build-python2.4, build-python2.5...

With constructs like:
================
PYVERS := $(shell pyversions -vr debian/control 2>/dev/null)

build-%:
PYTHON=`which python$*` ./configure
...

build: $(PYVERS:%=build-%)
================

And it doesn't even conflict with implemeting build-arch; it just makes
the test make moot.

glib2.0 has a very similar example for each of its flavors ("deb" and
"udeb").

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, Dec 07, 2007 at 08:23:28AM +0100, Loïc Minier wrote:
> With constructs like:
> ================
> PYVERS := $(shell pyversions -vr debian/control 2>/dev/null)
>
> build-%:
> PYTHON=`which python$*` ./configure

I guess this should have been "`which $*` ./configure", right? If so,
read on.

> build: $(PYVERS:%=build-%)
> ================
> And it doesn't even conflict with implemeting build-arch; it just makes
> the test make moot.

And what would you loose in using something like:

build-python%:
PYTHON=`which python$*` ./configure
...
build-arch:
...

?

Cheers

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ? / All one has to do is hit the
(15:57:15) Bac: no, la demo scema / right keys at the right time

On Mon, Feb 11, 2008 at 05:44:33PM +0100, Matthias Klose wrote:
> Moritz Muehlenhoff writes:
> > [This message has also been posted to gmane.linux.debian.devel.general.]
> > On 2007-12-25, Moritz Muehlenhoff <jmm@inutil.org> wrote:
> > > Matthias Klose wrote:
> > >> This is a proposal to introduce a common set of compiler options which
> > >> can be set independently from the package, and passed/injected to the
> > >> package build process. It was first discussed at the last UDS; a
> > >> corresponding wiki page can be found at [1].
> > >
> > > A change like that is more or less required for the planned introduction
> > > of security hardening features. Since noone really objected to the change
> > > outlined, I'd be interested in the way forward from here and what timeline
> > > is planned to set the changes into effect.
> >
> > Matthias, what's the status?
>
> thanks for the reminder; I did update the proposal and renamed the
> environment variables to what Colin Watson did suggest. Bug #465282
> now has a patch for dpkg-architecture attached.

That looks good to me. Maybe we should have individual default flags
per architecture, so that features, which are buggy or not fully
implemented on a given arch can be disabled so that the workarounds
don't need to be done by the maintainers across several rules files?

Cheers,
Moritz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Feb 14, 2008, Frank Lichtenheld wrote:
> Hmm, I doubt that dpkg-dev should be the place to keep track of that.
> I mean, that probably depends on the version of gcc/g++/whatever used,
> so it's quite meaningless to make it dependent on the version of
> dpkg-dev you use.

Should we have a new "default-flags" package or something which would
be the place where these flags are set? Perhaps queryable with:
get-default-flags --gcc
get-default-flags --ld
etc.

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org