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:
Bad:
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.
Good:
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:
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.
manoj
--
Unfair competition: Selling cheaper than we do. Kelvin Throop III, "The
Management Dictionary"
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
