Re: Environment variables, debian/rules and dpkg-buildpackage
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/
Reply to: