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

[ludo@gnu.org (Ludovic Courtès)]

Eric Bavier <ericbavier@gmail.com> skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier <ericbavier@gmail.com> skribis:
>>
>>> 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.
>>
>> OK.  The /no-such-path comes from the compile-time settings of our Bash,
>> in (gnu packages bash).
>>
>> We could perhaps fix it to refer to Coreutils, but that’s a bit
>> tricky.
>
> I'll fix our subversion, but we'll need to keep this option in mind in
> the future.  It doesn't look like it would be *too* tricky ;)

OK.

What would make it tricky is the fact that the “final” packages built in
(gnu packages commencement) must not retain references to the bootstrap
tools.  So the final Bash must refer to the final Coreutils, not to the
bootstrap Coreutils.

>>> 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,
>>
>> Yes, sounds good.
>>
>>> while also submitting a bug to libtool.
>>
>> I don’t think so.  Often, the problem is when such scripts contain
>> absolute file names, like /usr/bin/file, which we need to patch.  This
>> time they’re “doing it right”, so let’s not suggest the evil thing.
>> :-)
>
> My thought was that libtool could get the absolute file name to ls
> during configure, as it does already with a number of the other tools it
> uses.

Oh right, I had misunderstood your proposal.  That’s a good idea.

Thanks,
Ludo’.