From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks. Date: Tue, 25 Nov 2014 18:09:38 +0100 Message-ID: <87d28bfbql.fsf@gnu.org> References: <1416548468-28421-1-git-send-email-bavier@member.fsf.org> <1416548468-28421-2-git-send-email-bavier@member.fsf.org> <871towp5ze.fsf@gnu.org> <87ppcgtcoj.fsf@gmail.com> <87k32njy58.fsf@gnu.org> <87r3wriu5w.fsf@gnu.org> <87bnnvte9u.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtJcc-0006nD-0Y for guix-devel@gnu.org; Tue, 25 Nov 2014 12:09:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtJcS-0002Qj-VX for guix-devel@gnu.org; Tue, 25 Nov 2014 12:09:49 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:39711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtJcS-0002Qb-Of for guix-devel@gnu.org; Tue, 25 Nov 2014 12:09:40 -0500 In-Reply-To: <87bnnvte9u.fsf@gmail.com> (Eric Bavier's message of "Tue, 25 Nov 2014 10:51:09 -0600") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Eric Bavier Cc: Guix-devel , Eric Bavier Eric Bavier skribis: > Ludovic Court=C3=A8s writes: > >> Eric Bavier skribis: >> >>> The culprit, I think, is a small difference in behavior of bash. If PA= TH >>> 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 Gui= x'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=E2=80=99s 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 =E2=80=9Cfinal=E2=80=9D pack= ages 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 t= o 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=E2=80=99t think so. Often, the problem is when such scripts conta= in >> absolute file names, like /usr/bin/file, which we need to patch. This >> time they=E2=80=99re =E2=80=9Cdoing it right=E2=80=9D, so let=E2=80=99s = 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=E2=80=99s a good idea. Thanks, Ludo=E2=80=99.