Hi Joey, now that you're developing debhelper compat 9, it would be really nice to deal with #544844.
To me it's clear that the consensus is in favor of supporting calling debian/rules directly and I have taken steps in this direction while working on dpkg-dev (created dpkg-buildflags, not adding vendor variable in environment). It would be nice to have debhelper cope nicely with this decision, otherwise you effectively force us to let dpkg-buildpackage set the variables forever (or we break many more packages when we do the change). Replying more specifically to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544844#10 I think it's clear the problem is not the usage of the enviroment variables, but the fact that they had to be set by the caller of debian/rules. dh setting the variables is OK because dh is called by debian/rules and thus a caller of debian/rules does not have to provide anything in the environment. Furthermore I realized that it would be nice for dh to setup a complete environment at least when calling overrides targets so that we don't have to put lots of boilerplate code in debian/rules: - add if needed the dpkg-architecture variables (dpkg-architecture -l) - add if needed the dpkg-buildflags variables (dpkg-buildflags --export=sh) - set some convenience variables that we frequently compute with some custom shell command: source package name, first binary package name, version, upstream version I say "add if needed" because the boiler-plate code is usually FOO ?= $(shell) so you could set the variables only if they are not already existing. I hope it's enough to convince you. If not, please share your thoughts on how we should go forward with this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
