Hello,
On pirmadienis 20 Birželis 2011 09:08:53 Raphael Hertzog wrote:
> Hi,
>
> On Mon, 20 Jun 2011, Modestas Vainius wrote:
> > On the other hand, it is really too bad that 'export
> > DEB_LDFLAGS_{APPEND,SET} = ' will have no effect as long as
> > dpkg-buildpackage keeps modifying environment. Both LDFLAGS and
> > DEB_LDFLAGS_APPEND would need to be exported (or LDFLAGS unexported) in
> > order to be compatible with both old agressive dpkg- buildpackage and
> > envvars-friendly dpkg-buildpackage. But this is not clean in my book
> > (consider backports etc.).
> >
> > In order to make `export DEB_*_{APPEND,SET}` work with both dpkg-
> > buildpackage's, I propose the attached patch (0002). The patch also
> > tweaks documentation a bit wrt this topic. The patch should be safe but
> > it will override VAR envvar if either of DEB_VAR_{APPEND,SET} is
> > exported so I don't know if you want to add this to compat=9 (should be
> > trivial to modify).
>
> Hum, DEB_*_APPEND/SET were meant for users recompiling packages not really
> for package maintainers. The logic was that dpkg-buildflags gives a set
> of base flags and that the package can then tweak them.Those intentions are not clear from the manual page. > And since Joey already decided to not override the variables if they are > already set, the correct way to tweak a value is to retrieve it in the > rules file and to reexport it in the environment. I don't see the need > for your supplementary patch. Well, once again, that's not clear from the manual page. You can be pretty sure that some people wanting to avoid $(shell dpkg-buildflags ...) in rules (minimalism you know :-)) or to remember that "dpkg-buildflags ..." command or having no clue about dpkg-buildflags at all, may also think of a "smart way" to export those DEB_*_APPEND like I did. In my opinion, documentation has to be very clear on recommended practises. Personally, I think that those envvars are very easy target for abuse.... Anyway, then my patch is not really helping. Dh_Lib.pm part should be reverted and documentation should be fixed once we decide on the recommended practises. Having in mind #613046 , what's the recommended way to add -Wall to C(XX)FLAGS then? This should be put into dh(1). > That said for the sake of simplicity, it's probably a good idea > to improve dpkg-buildflags to support debian/buildflags.conf that would > be parsed after everything else (and that is clearly meant to be used by > the package maintainer). > > Do you agree ? I really don't think so. How many configuration files with alternating syntaxes do we need in debian/*? I have a feeling that debian/rules is starting to be become the least significant of them all. There should be the only good way (i.e. fewer possibilities for abuse) to do the same thing and it should be properly documented. -- Modestas Vainius <mo...@debian.org>
signature.asc
Description: This is a digitally signed message part.
