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

[Manoj Srivastava <srivasta@debian.org>]

On Wed, Mar 18 2009, Raphael Hertzog wrote:

> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>> 
>>         Modulo debhelper, cdbs, et.al can help.
>
> Debhelper can't help. Only CDBS can (as its design is precisely based on
> included Makefiles).
>
>>         And will be mostly useless. dpkg can set these variables until
>>  it is blue in the face, and it has zero effect on my packages  until I
>>  change my rules file. Or change upstream Makefiles to pay attention to
>>  the cflags set in the env. This is a major change for some of my
>>  packages, and without them the dpkg proposal does nothing.
>
> That's true for a lot of packages but not all packages. It also means that
> there is some usage of this approach in the archive (otherwise if all
> packages ignored the environment variables, there would never have been
> packages that FTBFS when this change was introduced in Lenny).

        Any package that follows policy §4.9 examples to set CFLAGS
 based on DEB_BUILD_OPTIONS will be immune to CFLAGS et al set in the
 environment.

        Also, any upstream Makefile that sets CFLAGS (don't most ones
 that use automake do that?) will also be not affected, unless even more
 hackery is done. At this point, what dpkg does to these variables not
 enough to justify any such effort.

> So according to your rule that policy should standardize "common
> practice" and not mandate something completely new, the env variable
> proposal is in more widespread usage.

        That was not my rule, just a misunderstanding of what I
 said. The rules is that policy
  a) standardizes practices needed for integration, and no more.
  b) when it must add stuff, policy tries to add the best, and minimal,
     solution. 
 c) Often the viability of s solution is not clear until it has been put
    into practice, and the kinks ironed out.

        This does not mean shoddy practices will be enshrined in policy.

> (Note that I don't find this rule particularly useful and that's why I
> didn't mention it before but since you ask about points where you are
> biased I thought it could be worth telling) 

        An incorrect rendering of the rule does not help, sorry.



>>         Also, the dpkg proposal  blurs the distinction between the site
>>  wide policy and project defaults, as far as the user or the package
>>  maintainer is concerned. This is a deficiency.
>
> While I agree that the distinction is blurred because in the rules files
> you don't know where the env var comes from, I don't agree that it's a
> deficiency.

        A missing feature is a deficiency. How critical a deficiency it
 is is a matter of opinion, and we  apparently differ.

> The rules files receives a value and should use it. It doesn't need to
> know whether it's the site-wide default or the distribution default. 
>
>>         Yup. The major differences are:
>>  With the dpkg proposal:
>>  Bad:
>>  o) people must always use dpkg to build packages, or the packages come
>>     out different
>
> If the policy document the fact that the rules files need some input
> variables, then it's not a big deal: if you really care about being able
> to call debian/rules directly you can always adapt your rules files
> accordingly like I suggested at the end of this mail:
> http://lists.debian.org/debian-devel/2009/03/msg00920.html


> We could even write such a Makefile that mimics more closely what
> dpkg-buildpackage does for people that care about it. But I don't
> really want to impose a Makefile snippet to everybody.


        Frankly, dpkg does very little: All it does is to discard the
 policy suggestion (which I think is a bad idea) and only sets FLAGS to
   -g -O0 or -g -O2

        I do not think that this is much of an assistance, if this is as
 far as dpkg goes.

        Setting CPPFLAGS, COPTS, CWARNS, CFLAGS, CMACHINE (and things
 for other languages) might be better, but trivially just setting CFLAGS
 to select between -O0 and -O2 is not enough to justify mangling build
 systems to 


>>  o) The user or the package maintainer can no longer tell the difference
>>     between site policy and project policy
>
> The user is intelligent, he can read the output of dpkg-buildpackage that
> tells him where the data comes from (or he can read the doc and the
> configuration file). In any case, it's comparable to having to
> read a Makefile snippet.

        With the makefile snippet, the Makefile can tell the difference,
 and there is a standard method to tell what variables are set in the
 site config.

> For the package maintainer, why should he care ? The variable is
> provided in a manner where he can or can't override it, but that's all
> that matters.

        Because it gives the option to override one or the other -- a
 generic default that is project wide might be less applicable, but site
 policies can still be followed.


        I think it is a useful feature. 

>
>>  o) The environment variables are set even if the package is not ready
>>     for them,
>
> We already took that hit. It's not an issue.


>>  o) rules file still need to be modified to take advantage of the
>>     variables set -- none of my rules files will be affected by any
>>     settings in dpkg right now.
>
> The fact that your rules files need change doesn't meant that all need it.

        Anything that follows policy §4.9 needs it.

>>  With the Make snippets proposal:
>>  Bad:
>>  o) Every package has to change (but,every package has to change anyway,
>>     since currently dpkg can set the variables till it is blue in the
>>     face and nothing will take effect in my packages)
>>  Good:
>>  o) the person building the package is not constrained to using dpkg;
>>  o) The site admin can add on to the variables set on that site, and is
>>     not constrained by what dpkg handles
>>  o) the process is opt in, and packages opt in to using the new
>>     mechanism when they are ready.
>>  o) The end user can override project, site, or package policies,
>>     individually, or in any combination
>> 
>>         If I am biased (likely), please tel me where I have gone wrong
>>  above. 
>
> If the policy documents the environment that needs to be setup, nobody is
> forced to use dpkg-buildpackage to do it. But it's probably more
> convenient to use a helper compared to manually setting the expected
> variable.

        I think that there has to be more of a justification of why the
 rules files need to be hacked, upstream Makefiles need to be hacked,
 and for what?

        All packages already need to select between -O0 and -O2 or they
 fail policy §4.9. What does adding this bit to policy buy us?

        manoj
-- 
ignorance, n.: When you don't know anything, and someone else finds out.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C