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

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

On Mon, Mar 16 2009, Russ Allbery wrote:

> Raphael Hertzog <hertzog@debian.org> writes:
>> You're not trying very hard to look from both sides: whether the default
>> value comes from the environment or from an included Makefile, in both
>> cases the user can override it with command-line arguments.
>> Granted it means that dpkg-buildpackage would have to pass
>> user-overriden flags on the command line instead of using the
>> environment, but that can be done if people really want this
>> possibility.
> I think it's clearly mandatory to implement a hierarchy of settings:
> * Debian defaults
> * Local distribution overrides
> * Local package overrides
> * User settings
> where each overrides the previous ones.

        We can do better than that with the Make snippets.

        Say, as an user, I think my admin is nuts, and I want o
 override his setting, and revert to the project wide default, for all
 packages I build on this machine. Easy (just set site_foo in the env,
 call debian/rules with -e).

        Or, as an admin, I want to always override the project wide
 settings (hey, I like hardening flags), but on some machines I have
 taken time out to set up site wide defaults -- and I do not want to
 over ride those. Again, easy to do with the example snippet I posted.

        All kinds of flexibility become ours once we embrace toe
 sour^H^H^Hsnippets, I mean.

> Personally, I'd rather see this done via an included make fragment.  I
> think the logic in debian/rules is simpler in that case, and I don't
> agree with the argument that it's that much harder to implement than
> relying on environment variables.  In practice, huge numbers of Debian
> packages already unconditionally set CFLAGS in debian/rules and hence
> override any environment variable settings.  All those packages are
> going to have to be modified anyway.  I don't see a way of
> meaningfully deploying this change without modifying most of the
> archive.

        The advantage of the snippet approach is where packages might
 break if the builtin defaults are changed will not be broken by the
 snippet approach, since the change is opt-in.

It is a city built of bones, and daubed with flesh and blood, in which
old age and death, pride and hypocrisy are the inhabitants. 150
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: