Roland Mainz wrote:
> Mike Sullivan wrote:
>> Roland Mainz wrote:
> [snip]
>>> Mike.Sullivan at sun.com wrote:
> [snip]
>>> ... which leads to a question: Shouldn't "bldenv"&co. clear the
>>> environment except those env variables which are "known to be good" ?
>> they try, though they have evolved by removing those known to be bad
>> rather than just leaving those known to be good. The problem is that
>> those variables change over time as things get integrated, and is
>> particularly bad in sfw where we don't control most of the Makefiles.
>> So things that we think of as 'good' today might not be 'good' tomorrow.
>
> Do you have any specific examples ? The variable list in my previous
> email listed those who are expected to be available in a normal Unix
> login environment + X11 variables (e.g. for X11 editors) - what else
> would be needed (right now I can't think about any examples) ?
No - but I cannot predict the future. Like I said, even if your list
is good today, if somebody integrates something that has a Makefile
that wants DISPLAY to be a list of object modules for 'libdisplay'
or something then that could then be a bad variable to let through.
I would never have imagined that PROFILE would break postscript - but
it does.
>>> ... question to the gatekeepers: Should I file a RFE to let "bldenv"&co.
>>> clear the environment ? I would add to new options: --acceptenvvars and
>>> --rejectenvvars which accept patterns (shell patter, grep pattern, egrep
>>> pattern, fgrep pattern or perl pattern) to filter out environment
>>> variables by name. Any variable name which does _not_ match the pattern
>>> for "acceptenvvars" will be removed and any variable name which matches
>>> the pattern for "rejectenvvars" will be removed, too (e.g. a traditional
>>> accept/reject filter chain).
>> there is already a bug for making nightly start off with a clean
>> environment, you should probably just go fix that and then we
>> never have to worry again.
>
> Erm.. that is technically what my patch would be doing... I only provide
> two additional "tuneables" so people can change the list on demand
> without having to hack "bldenv" first.
And I tend to not like tuneables that could let you get in trouble - it
would be bad to tweak your build with them and then putback and have
the gatekeepers/gatelings find out the defaults don't work.
>> I don't really see a need to let people selectively add/subtract
>> variables as that just looks like more ways to make builds differ
>> or break. And if you really need to add variables to the environment
>> you can already add them to the env file.
>
> Right - but see my comment above - since requirements may evolve over
> time I want to add some tuneables to adjust the filter chain on demand
> (hey - it's my burden to get the filter right)
And if it needs to change later because somebody wants to integrate
foo but can't without changing the tools, then that's an issue.
I just think we can fix this once and for all by not letting the
environment through. So why not? It's not like passing the environment
through was ever a great feature that I'm aware of - it comes from
when nightly was root-only (with a fairly small/controlled environment)
and only run by the gatekeepers long long ago. And while you could
argue that bldenv is something done interactively so you might want
more login-type variables set so you could run gui's, I'm not sure
that would be a wise difference either since bldenv is supposed to
replicate the exact setup nightly had - and now it wouldn't, unless
you let those variables through in nightly too, thus risking that
some Makefile will use them....
It just seems better to me to have them both dump the environment
first. But I'll let others respond now since there's not much else
I can say :)
>
>>> I already have a contribution for "bldenv" queued (CR #6600149
>>> ("bldenv_cleanup")) and could easily integrate the functionality into
>>> it... "nightly" would follow with a seperate CR# and putback once we
>>> have positive feedback from that putback that the change worked...
>> actually no - you need to make sure the change works before you
>> putback.
>
> I know that... however changing both "bldenv" and "nightly" is a bit
> time-consuming and I prefer to handle these scripts one-by-one (CR
> #6600149 is special in this case since we don't introduce new
> functionality (erm... which isn't 100% true since stuff like $ bldenv
> --man # will now work and boolean options now support true/false as
> required by POSIX/SUS, e.g. "-d" enables debug builds, "+d" disables
> debug builds again)).
well things that are bldenv-only can certainly be done separately. But
were you to do something like selectively let bldenv (or nightly)
pass through variables, I'd expect both to be modified to do it at
the same time since they are often used in conjunction, so if
you used a new option to nightly to tweak something, then tried to
build in that workspace to fix a problem, you'd probably need to
do the same thing with bldenv. That's just doing a complete job.
And certainly some you simply have no choice (you couldn't allow
new options in NIGHTLY_OPTIONS that one understands and the other
doesn't).
Mike
