Package: dpkg-dev
Version: 1.16.1.2
Severity: wishlist
File: /usr/bin/dpkg-buildflags
Hi folks,
I've been reading up on dpkg-buildflags, hardening et al, to get my
dh-based package to as compliant as possible. However, I got quite
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'll try to pinpoint the sources of confusion and/or information I was
missing there and try to suggest improvements where possible (but I'm
not 100% sure I actually understand thing enough yet...).
- I couldn't find what the best way was to use the build flags. I think
there are a few options:
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.
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.
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.
Explicitly mentioning these options in the manpage (and perhaps even
picking one as recommended practice?) would have helped me when
figuring out this stuff.
- If you actually pick one of the above options, implementing them is
the next step. It would help if the manpage provides some examples.
For example, including a single variable in your rules file is as
easy as
CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
but it would save a lot of time if people could just copy something
like this from the manpage.
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.
- 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?
- On a related note, perhaps the dpkg-architecture manpage should refer
to /usr/share/dpkg/architecture.mk as well?
- 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?
- The manpage shows a list of supported flags, but does not say whether
that list is fixed or might be expanded in the future.
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.
Gr.
Matthijs
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
