Raphael Hertzog <hert...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
