OK, here's a better patch for MKCL and ASDF. You were having ASDF re-load itself before it's configured; that's the recipe for loading the one that is in the user's normal configuration, environment variable or not. Later in the script, you correctly configure ASDF, and ASDF 3 does its own reloading automatically, so you don't need this step. Actually, if you're upgrading from ASDF2, you'll need more steps than that, before of the package punting; but you're not, are you?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Poetry is what gets lost in translation." — Robert Frost
On Wed, Apr 9, 2014 at 8:36 AM, Faré fahree@gmail.com wrote:
This suggests that one of the things you need to do is have tighter control over the CL_SOURCE_REGISTRY and ASDF_OUTPUT_TRANSLATIONS around this compilation, to prevent the unwanted ASDF upgrade.
I have to admit that interference from the process environment was not on my list of identified threats. I just committed two lines in my src/build-asdf-contrib.lsp to guard against that. I hope its enough. I looked into the source code of ASDF and saw that it read the content of at least 11 environment variables! Should I be paranoid and guard also against the 9 nine others beside the two you mentioned?
grep 'getenv.*"' *p u*/*p actually finds 15 different variables that *may* be used. But when these two are controlled, all other variables are unused, except for __CL_ARGV0 that you shouldn't care about and TMPDIR (or TEMP, on Windows) that should be left in the user's control — if it's bogus, a lot more things than ASDF will break; and if the user wants to divert it, he probably knows what he's doing.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond