Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks.

[Eric Bavier]

On Sat, Nov 22, 2014 at 5:02 AM, Ludovic Courtès <address@hidden> wrote:

Eric Bavier <address@hidden> skribis:

> On Fri, Nov 21, 2014 at 4:24 PM, Eric Bavier <address@hidden> wrote:
>
>>
>> Ludovic Courtès writes:
>>
>> > Eric Bavier <address@hidden> skribis:
>> >
>> >> * gnu/packages/patches/subversion-propagate-env-to-hooks.patch: New
>> patch.
>> >> * gnu-system.am (dist_patch_DATA): Add it.
>> >> * gnu/packages/version-control.scm (subversion): Use it.
>> >
>> > [...]
>> >
>> >> +++ b/gnu/packages/patches/subversion-propagate-env-to-hooks.patch
>> >> @@ -0,0 +1,14 @@
>> >> +* Hooks need to inherit environment variables such as PATH, otherwise
>> simple
>> >> +  things like `ls` might fail in a hook.
>> >
>> > That looks good, but I want to make sure we’re not changing something
>> > that was purposefully made this way.
>>
>> If the behavior is similar in 1.8.10, I'll get in contact with the
>> developers.
>>
>
> According to the subversion documentation, the desired behavior is to
> execute hooks in an empty environment for security reasons (see
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.create.html#svn.reposadmin.create.hooks
> ).

OK, so I think it’s important to stick to this behavior.

Agreed.
 

> So it looks like this is a small bug in libtool.  The wrapper scripts
> libtool generates for programs use `ls' to resolve symbolic links and is
> the only utility program invoked without an absolute file name (the only
> other utility being sed).  If such a wrapper script is executed with no
> PATH set, then we get "ls: command not found" errors.  I don't think it's
> unreasonable to expect libtool's wrappers to be able to execute in an empty
> environment.

I see.  So the patch is there “just” to allow tests to run, right?

Only for tests to pass, yes.

 

Second, the problem should affect everyone, including FHS systems, no?

The culprit, I think, is a small difference in behavior of bash.  If PATH is unset (such as within svn's hook environment), then `bash -c 'echo $PATH'` on an FHS system prints something like "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", but Guix's bash prints "/no-such-path".  In the first case, `ls` will resolve to "/bin/ls", but will not be found in the second.

 

How do people work around it?

Given that behavior, people have nothing to work around.  Does Nix's bash behave differently?

I'm not sure that our bash needs to be changed in any way.  It's current behavior seems in line with Guix's way of things.

I was able to get the tests to pass by simply patching the references to ls that libtool emits in its wrappers.  I think this might be the way to go for now, while also submitting a bug to libtool.

Thoughts?

`~Eric

--

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html