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.
Attachment:
pgpDkBoEgFO00.pgp
Description: PGP signature