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

Re: About Debian bug 246061, suppress environment variable



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> > I think it is better to add "unset NAME" construction to configuration
> > file, that will unset an individual variable in current
> > mode/package/scope.
>
> I hope it will work on package basis. Or will it be possible to unset on
> scope and mode basis too?

I think of sequential interpretation semantics.
Currently, config file is read line-by-line, and executes all 'variable 
setting' statements if mode/package/scope match. I think to add one more 
statement that, when executed, will unset variable.

> > I was goind to add it long ago, but still didn't actually add the
> > code. I may try to add it this evening.
>
> Put this into your consideration. dpkg-cross define today a bunch of
> variables. Nobudy really know which ones are defined without review the
> sources (Ore are those documented in man pages?) If we will introduce
> new variables old cross-compile scripts won't work because new
> introduced variables have to be "unset" by the developer afterwards.
>
> If we would say that _all_ variables are unset by dpkg-cross future
> introductions of vairables would not affect old cross-compile
> configurations. This is one advantage of this approach.

What do you think of idea of making everything explicit (that means, no 
implicit variable settings at all)?  This will break compatability, but we 
may warn loudly pointing user to NEWS.Debian if some important variable 
(such as CC) is not set.

I also thing that "base" variables (crossdir, crossprefix, etc) should 
depend at least on mode component of mode/package/scope. This is needed, 
for example, to make it possible to intruduce a mode for uclibc builds and 
a mode for glibc builds.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/7YVsTbPknTfAB4RAkMeAKCwmIlUqedjngfZnqgRDBZcGUrh4ACferqY
j85TK2dvXSSPoIfuU0Nit7E=
=0t4T
-----END PGP SIGNATURE-----



Reply to: