Hi, On Fri, 27 Jan 2012, Matthijs Kooijman wrote: > confused about what I should do and how I should do it. Instead of > (possibly badly) reinventing the wheel, I think it would be better to > improve documentation. > > One particular area of improvement is the dpkg-buildpackage manpage.
I don't think that dpkg-buildpackage is the right place for any documentation related to hardening. If you find something to change there, please tell me what. But the new documentation that you're requesting should definitely find its way in dpkg-buildflags(1). > - I couldn't find what the best way was to use the build flags. I think > there are a few options: The recommended ways have been mentionned on -devel-announce: http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html > 1. Include all buildflags (using --export=make for example) and > export them into the environment and let ./configure and/or make > pick them up. This is the easiest approach, it will work in most > cases (and might even work in the future when new buildflags are > added). However, this is also means that builds could be passing > variables for which the maintainer has not verified upstream > support, so there's also a change of things breaking. The list of build flags will not change often. I would not fear breakage by the introduction of new build flags. And if one of the existing flags is not supported, it's usually just not supported and doesn't break anything. (The exception being LDFLAGS where some upstream build system are using it incorrectly as a variable passed directly to ld instead of passed to ld via gcc). > 2. Explicitly call dpkg-buildflags for each flag that is know to be > supported/appropriate by/for the upstream buildsystem. This is > probably the most robust and well-readable way, but does require > maintainer action whenever a rul is added. And it's a bit too verbose for my own taste. I like short rules files. > 3. A mix of the above: Include all buildflags, but only mark some of > them for export (and/or only explicitely pass some of them to > ./configure and/or make). This keeps the code required in > debian/rules short, but prevents unexpected results in the future. Yeah, this was also suggested as a possibility in the -devel mail. > Explicitly mentioning these options in the manpage (and perhaps even > picking one as recommended practice?) would have helped me when > figuring out this stuff. Right. > Also, how to include _all_ variables at once is not quite clear to > me. There is this --export=make option, but I'm not sure if I should > just eval the result (since I've read that that breaks on newlines > or something) or output to a file and then include that (but should I > then remove the file on clean, or?), etc. --export=make is wrong good idea, I wish I did not introduce it at this point. I don't remember the details but there were multiple problems trying to let make eval its output. > - There seems to an alternative to calling dpkg-buildflags, namely > including buildflags.mk. I orginally thought this was some > alternative to calling dpkg-buildflags that existed next to > dpkg-buildflags (and might not honer DEB_BUILD_OPTIONS), but only > later I found that buildflags.mk actually just calls dpkg-buildflags. > > This means that it's actually the shortest way to include all > variables into /debian/rules. Including a note about this would make > sense? Yes. > - On a related note, perhaps the dpkg-architecture manpage should refer > to /usr/share/dpkg/architecture.mk as well? This has been made recently in the git repository. > - It would be good if the dpkg-buildflags manpages would mention that > debhelper / dh (not sure which?) automatically calls dpkg-buildflags > and exposes all relevant variables, starting with compat level 9. > Strictly speaking, this is not something dpkg-buildflags should > document, but a small headsup won't hurt? You're right, it's not something that dpkg-buildflags should document. :-) So we won't document it. > - The manpage shows a list of supported flags, but does not say whether > that list is fixed or might be expanded in the future. It might be expanded if there's some need at some point (i.e. new language with new buildflags?). > So far my observations looking at the manpage as a (somewhat) clueless > newbie. If someone can comment on my observations and correct me where > needed, I'm willing to see if I can turn my suggestions into written out > proposal or a patch. Great, I look forward to your patch. :-) Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
