[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Environment variables, debian/rules and dpkg-buildpackage



Raphael Hertzog <hertzog@debian.org> writes:
> On Tue, 12 May 2009, Russ Allbery wrote:

>> Why would you want to disable all hardening instead of filtering out
>> the flag that breaks the package?

> Because no-one has identified the precise flag that breaks the package?

Then filter out the ones that might cause the problem.  Last I heard,
we're only talking about two or three flags here and they weren't
changing particularly fast.

> Or because you really want no hardening at all because you don't want to
> have to deal with subtle breakages caused by a supplementary
> hardening flags added later?

It sounds like you're thinking that we could potentially change the
hardening flags down the road without going through the same checking
and care that we did when introducing them in the first place.  I'm
fairly sure that's unrealistic.

> I know that we always have many different opinions when it comes to
> implement some new stuff and I'd rather have some supplementary
> flexibility that is not needed rather than finding atferwards that we
> need more of it because when it concerns the whole archive, it's
> painful.

I think that having a big switch that turns on (or off) some
unrestricted set of hardening flags that may change in the future is not
horribly useful flexibility.

> We suppose all packages already have the right include that imports
> the default cflags. So now, you decide it's time to use hardened flags
> by default so you just change the default flags. Is that right?

Correct.  Obviously you'd have to do a lot of preparation before doing
that sort of global change.

> How did we enable hardening flags on individual package before (in
> your scenario)?

If DEB_BUILD_OPTIONS contains "hardening", the package would add the
contents of DEB_BUILD_HARDENING_CFLAGS to CFLAGS and
DEB_BUILD_HARDENING_LDFLAGS to LDFLAGS.  (For example.  There are other
ways it could be done, but that's the one that comes to mind.)

At some point we'd add a nohardening DEB_BUILD_OPTIONS setting that
would disable hardening flags for people who wanted to do a build
without hardening and then add the hardening flags to the default flags
iff that option isn't set.  (Assuming we decide to make hardening the
default.)

> What were maintainers supposed to do in advance to disable some
> hardening flags that break their packages given that they don't even
> know for sure what the default flags will look like.

Surely that's not a situation anyone would be in.  It supposes that
we'll be in a situation where we're about to make hardening the global
default and yet we don't know what flags will be in it.  If we're in
that situation, we screwed up, and we need to go back and finalize the
flags before we talk about changing the defaults.

> Not sure at all. In part because only a small percentage of the
> packages would benefit from it (those that build arch: all and arch:
> any and where the work to compile doc for the arch: all is
> expensive). So targetting a MUST in policy is overkill in my opinion.

That would argue for not doing it for all packages and instead providing
some way to say it's supported, and yeah, that's the case where I can
see having Build-Options-Supported.  Although I also think it's becoming
increasingly easy to add the build-arch and build-indep targets.  If one
added them to debhelper's rule minimization and cdbs, you'd already
catch a large percentage of the archive now.

Either way, we shouldn't base it off Standards-Version; that bothers me
much more than Build-Options-Supported does.  :)

> Maybe the right thing to do is to make it mandatory only for packages
> that have both arch-indep and arch-specific binary packages.

It's really fairly rare that this matters that much, so yeah, the more I
think about it, the more you're probably right and this is a case where
the package should be able to communicate back to the build system that
it supports doing something.  I have a ton of packages with both
arch-independent and arch-specific binary packages, but only one of them
would gain anything from this split.

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


Reply to: