Re: support for non-list search paths

[Ludovic Courtès]

Troy Sankey  skribis:

> From faf99fec917115cdce11b48e5bb68159322c9eef Mon Sep 17 00:00:00 2001
> From: Troy Sankey 
> Date: Mon, 6 Mar 2017 19:31:02 -0500
> Subject: [PATCH] gnu: git: force GIT_EXEC_PATH to be single-entry
>
> * gnu/packages/version-control.scm (git)[native-search-paths](separator):
> New field.

Applied to ‘core-updates’, thanks!

Ludo’.

Re: support for non-list search paths

[Troy Sankey]

Quoting Ludovic Courtès (2017-03-06 16:22:52)
> Hi,
> 
> Troy Sankey  skribis:
> 
> > My workaround involves using `guix package --search-paths=exact`, but
> > this cost me some time debugging which I'd like to save the next person.
> > I am not sure what the solution should be.  Maybe just a clarification
> > in documentation?  What about an argument for search-path-specification
> > to force the variable to always be "exact"?
> 
> This last option has been implemented in the ‘core-updates’ branch,
> which is meant to be merged Real Soon (hopefully within one or two
> weeks):
> 
>   https://bugs.gnu.org/25422

Wow! yay!

Troy
From faf99fec917115cdce11b48e5bb68159322c9eef Mon Sep 17 00:00:00 2001
From: Troy Sankey 
Date: Mon, 6 Mar 2017 19:31:02 -0500
Subject: [PATCH] gnu: git: force GIT_EXEC_PATH to be single-entry

* gnu/packages/version-control.scm (git)[native-search-paths](separator):
New field.
---
 gnu/packages/version-control.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 9cbd49220..d2ddfeef0 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -295,6 +295,7 @@ as well as the classic centralized workflow.")
(files '("etc/ssl/certs/ca-certificates.crt")))
   (search-path-specification
(variable "GIT_EXEC_PATH")
+   (separator #f) ;single entry
(files '("libexec/git-core")
 
(synopsis "Distributed version control system")
-- 
2.12.0



signature.asc
Description: signature

Re: support for non-list search paths

[Ludovic Courtès]

Hi,

Troy Sankey  skribis:

> My workaround involves using `guix package --search-paths=exact`, but
> this cost me some time debugging which I'd like to save the next person.
> I am not sure what the solution should be.  Maybe just a clarification
> in documentation?  What about an argument for search-path-specification
> to force the variable to always be "exact"?

This last option has been implemented in the ‘core-updates’ branch,
which is meant to be merged Real Soon (hopefully within one or two
weeks):

  https://bugs.gnu.org/25422

Ludo’.

support for non-list search paths

[Troy Sankey]

The file "~/.guix-profile/etc/profile" treats all search paths as
colon-separated lists.  Some variables are not supposed to be lists, but
treating them as such could confuse programs which read them.
GIT_EXEC_PATH is one that has caused me trouble, so I'll be using it as
an example below.

The relevant line from "~/.guix-profile/etc/profile":

% grep GIT_EXEC_PATH ~/.guix-profile/etc/profile
export 
GIT_EXEC_PATH="${GUIX_PROFILE:-/gnu/store/9wwv7rl8n6ydcpa0h22nd38amwssfrbh-profile}/libexec/git-core${GIT_EXEC_PATH:+:}$GIT_EXEC_PATH"

Here's what my GIT_EXEC_PATH looks like from a terminal emulator:

% echo $GIT_EXEC_PATH
/home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core

Here's the error from git:

% git rebase
/home/sankey/.guix-profile/libexec/git-core/git-sh-setup: line 46: 
/home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core/git-sh-i18n:
 No such file or directory

Since my shell rcfile is sourced twice, GIT_EXEC_PATH becomes a
colon-separated list.  Double-sourcing the shell rcfile may not be the
only way to surface this issue.  If my rcfile simply set GIT_EXEC_PATH
before sourcing "~/.guix-profile/etc/profile", then I would still end up
with a corrupt GIT_EXEC_PATH.

My workaround involves using `guix package --search-paths=exact`, but
this cost me some time debugging which I'd like to save the next person.
I am not sure what the solution should be.  Maybe just a clarification
in documentation?  What about an argument for search-path-specification
to force the variable to always be "exact"?

Troy


signature.asc
Description: signature