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). 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. (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) > See, I think we need have package opt-in in any case. Not in all cases. CDBS could also be updated to cope with the env var and debhelper 7 packages using rules.tiny could also make use of it without a modification. > 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. 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. > 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. 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. > 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. > 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. dpkg-buildpackages should be considered like a helper and I'm available to fix any problem that makes it painful to use (if you find its usage too much constraining). I would like to point out that we speak mainly of CFLAGS and al. but that I also included DEB_VENDOR in the set of variables. This variable is not used currently (as I just introduced it with dpkg 1.15.0) but I expect it to become more used in the future for things like this: - enable additional patch/features depending on the vendor (while still sharing a common source package for better cooperation) - special purpose derivative could change the behaviour of helpers like debhelper/CDBS based on this value (for example to strip doc for Emdebian, to extract debug infos in .ddeb, ...) Most packages would not have to be modified to benefit from this variable because the derivatives would have designed their solution with this goal in mind. And it also concerns arch: all packages whereas CFLAGS only concerns arch: any. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
