Raphael Hertzog <hert...@debian.org> writes:
> On Mon, 27 Sep 2010, Russ Allbery wrote:
>> ...it gets derailed by this feature request for Build-Features, which a
>> lot of people are much more dubious about (myself, for example: I think
>> hardening flags should be handled similarly to parallel build flags,
>> not via Build-Features). So I think solving this problem via the
>> Build-Features route is going to keep struggling as long as that's
>> always closely linked to using Build-Features to change compiler flags.
> Well, I don't make it a requirement to implement it right now and the
> Build-Features code can certainly start with just the build-arch
> stuff. But I want to make sure we gave it enough thought so that it's
> not problematic later on to extend it to other similar but slightly
> different needs.
Is there anything about the syntax:
Build-Features: build-arch
to indicate that the package supports build-arch/build-indep targets (I
don't see any point in supporting one and not the other) that you think
would cause a problem for future expansion? I'd add a note that if there
are other build features, they'll be a comma-separated list of similar
keywords.
If not, can we just move forward with that and worry about the hardening
flags and the rest later? I really don't want to tie these things
together; one of them is something we all agree is broken and all want to
fix, and the other is much more of a can of worms.
The Policy bug otherwise seemed to have a fair bit of consensus and was
waiting on a dpkg-dev implementation. (I do think Build-Features is a
better header name than the originally-proposed Build-Options.) The only
other proposed solution in the bug was to just require
build-arch/build-indep, and I think that would be more disruptive.
>> IMO, Build-Features should declare interfaces and capabilities that the
>> source package supports, not a desire for the build system to change
>> other things about the build environment.
> I'm not sure how you can draw a clear line here.
The line that I would draw is between whether one needs to know in advance
whether a package supports a particular feature and whether one can just
request that feature and if it works, great. For hardening flags, I'm
missing the use case for needing to know if the package supports the flags
in advance, as opposed to just making hardening flags available for the
package to use if it supports them.
The reason why we're introducing Build-Features here is because there's no
good, safe way to just start using build-arch/build-indep without making
lots of packages fail to build from source.
> Supporting dpkg-buildflags to inject flags in the build process is an
> interface. Building successfully (and working afterwards) when hardening
> flags are injected is a "capability" or a "feature".
I don't really want to get into an extended discussion of hardening flags,
since there are a lot of problems and it will once again derail the
discussion of fixing the build-arch problems. Adding arbitrary hardening
flags that change over time is more than a capability; it's an
undeterministic capability. Since there's no limitation on what could be
added to hardening flags, there's no way for any package to safely declare
that capability and know that it won't break later when the hardening
flags change. It's a different type of problem, and I'm not sure the same
solution would be useful. But we should have that discussion separately
and just fix build-arch without tying it to that problem.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tylasx92....@windlord.stanford.edu
