[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Tue, Mar 17 2009, Stefano Zacchiroli wrote:

> On Tue, Mar 17, 2009 at 11:36:07AM -0500, Manoj Srivastava wrote:
>> # in debian/rules
>> -include  /etc/buildpackage.mk
> 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.

> AFAIU Raphael's proposal, the site-specific configuration will be
> achieved via dpkg-buildpackage config's file, without needing to
> include anything explicitly in debian/rules, while you are insisting
> in the explicit include.

        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.

        See, I think we need have package opt-in in any case.

        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 understand (though I disagree) with your reasons for having
> that include, that looks like a major differences in the two positions
> still.

        Yup. The major differences are:
 With the dpkg proposal:
 o) people must always use dpkg to build packages, or the packages come
    out different
 o) The user or the package maintainer can no longer tell the difference
    between site policy and project policy
 o) The environment variables are set even if the package is not ready
    for them,
 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.
 o) There is no transition period involved -- except that rules files
    still need to be modified, so there is a transition period anyway.

 With the Make snippets proposal:
 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)
 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

Unfair competition: Selling cheaper than we do. Kelvin Throop III, "The
Management Dictionary"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: