Re: PKGSRC_SETENV?= ${SETENV} -i

Aleksej Saushev <asau%inbox.ru@localhost> writes:
> Above you make assumptions as if our users set environment variables
> so as to penetrate pkgsrc protection and cause damage. I don't quite
> understand it. Users don't control autoconf cache from their .profile
> usually, and if they do, they know what they are doing.
> I don't understand why you treat pkgsrc user as some kind of adversary.
> You cannot be sure that /usr/bin/cc isn't specially crafted binary that
> unwraps after pkgsrc wrappers. Do you really want to address this issue??
>
> Environment variables are useful tool, and nobody uses them blindly
> without any reason. If pkgsrc user really wants "extra clean" build,
> he is capable of running bmake inside "env -i". I don't see reason to
> introduce this sort of cleanup at all. If anything, it should be
> additional wrapper around bmake, say, "pkgmake", that does
> "env -i PATH=... bmake". Doing otherwise breaks sane and useful
> use cases.
I basically agree with schmonz@. I have a project with a complex build
system that includes NetBSD and pkgsrc as components. We had an actual
problem with an environment variable leaking in from the outer wrappers
into pkgsrc builds causing unintended (breakage) consequences. So we
renamed it, because that was the easy thing at the time. But we had in
fact "blindly used a variable" without regard to other interactions.
Arguably the correct fix is to add a mk.conf setting for each thing that
people want to change about the pkgsrc build environment. Another
approach that is less architecturally pleasing but a good escape valve
is to allow setting environment varables in /etc/mk.conf, so that people
who want a particular variable in the build can have it.
As I see it, the point is not to stop people from intentionally changing
their builds. It's to stop arbitrary environment content from
*un*intentionally changing build output.