Manoj Srivastava <srivasta@debian.org> writes:

> I am convinced that this bug report is of dubious value, and if
> Russ agrees, I am going to just mark this report as closed, or as
> wontfix.

Yup, I tagged this one dubious myself a while back. I agree with closing
it. I know that not everyone agrees with the requirement, but given that
it's been in policy from 2001, I think we need a clear consensus to change
it, and I haven't gotten the impression that such a consensus exists.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
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:54:29PM +0100, Loïc Minier wrote:
> 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.

Then why in the world are you using "build-%" if you don't support
build-arch? What other values of '%' are you using?

WRT policy standardization, that sounds like a fairly pathological use of
wildcards, IMHO.

--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


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

On Tue, Dec 04, 2007 at 08:50:15PM +0100, Frank Lichtenheld wrote:
> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> > === Alternate naming of the macros ===
> >
> > Do omit the 'DEB_HOST_' prefix and all packages should honour the
> > value of CFLAGS etc. in the environment. Many packages are likely to
> > do this by accident anyway. For packages that set CFLAGS etc., there
> > are basically two common cases:
> [...]
> > It has the disadvantage that these macros might be injected into the
> > build for some non-standard build systems.
>
> If we would choose to use the common names without DEB_HOST_ prefix
> should dpkg-buildpackage then honor them if they are already set in
> the environment? Probably not as this seems error prone.

FWIW, I suggested this because I think it's a lot less work to fix up
the specific packages that get this sort of thing wrong than to enhance
nearly every package in the archive to support a whole new environment
variable naming scheme, go round checking that they support all the
things you care about (since you'd have to deal with them all
individually, support special debian/rules fragments to do this for
evermore, and so on. It just seems an order of magnitude less work to
say "thou shalt honour CFLAGS etc. if they're set in the environment",
and much more in line with how build systems often already work.

What possible errors are you thinking of, other than "debian/rules fails
to honour a certain variable" (i.e. the status quo)? I can't really
think why you'd set CFLAGS in the environment without wanting it to be
honoured.

--
Colin Watson [cjwatson@debian.org]


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

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.

Cheers,
Moritz


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

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?

Cheers,
Moritz


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

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.

Matthias


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

On Wed, Feb 13, 2008 at 10:01:00PM +0100, Moritz Muehlenhoff wrote:
> 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?

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.

Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/


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