[petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash

[Gerard Gorman]

Barry Smith emailed the following on 06/06/12 17:30:
> On Jun 6, 2012, at 11:26 AM, Jed Brown wrote:
>
>> On Wed, Jun 6, 2012 at 11:24 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> With all the other unneeded bells and whistles in hg, why doesn't it have a mechanism where WE can put this post-pull business into the repository instead of telling each user to do that?
>>
>> Massive security hole?
>>
>> Sometimes I like to be able to look at code without running it. I've seen "make" run "rm -rf ..". Just because I don't trust someone doesn't mean I don't want to look at their code. It would be a very bad thing for Hg to run arbitrary code when someone clones.
>    Did I ever say a mechanism to "run arbitrary code"?  I do not believe I did, nor did I even hint at running arbitrary code. What I want is a mechanism to run another hg command, in fact a specific hg command. Not "arbitrary code".
>
>    Barry
>
>

I often get tripped up by this and can understand how it can get
annoying. In svn land this issue would be formally handled by externals,
but the concept doesn't really carry to mercurial. One conclusion on
stackoverflow was just to pull in the external repository entirely:
http://stackoverflow.com/questions/217523/can-i-emulate-svnexternals-using-mercurial
Likewise, for our codes when we used svn we did use externals. But they
are a major pain because you have to manage the comparability between
the different repository revisions - making it awkward to roll back the
code to an early release when bug tracking for example. Eventually we
gave up trying to manage the insanity and just pulled in any external
repositories and merge in diff's to these externals when required/desired.

If pulling in the external wasn't an option, I like the second
suggestion on stackoverflow where they suggest coding it into the build
process. If that also isn't an option, then perhaps a warning from
configure could be useful.

Cheers
Gerard