Hi Eric, Eric Bavier skribis: > In gnu/packages/aux-files/run-in-namespace.c:620-626 we try to calculate the name of the relocated store directory. So > far this calculation seems to "accidentaly" work: > > /tmp/pack-dir/gnu/store/78xrsg1z...-emacs-no-x-27.1R/bin/emacs > /gnu/store/w9csar3m...-emacs-no-x-27.1/bin//emacs > > The "R" suffix appended to the wrapper store directory name and the double-slash we get from find-files (c.f. > guix/scripts/pack.scm:881) "cancel out". But we might not be so fortunate and can get something like this: > > | > /tmp/pack-dir/gnu/store/80|kbbxnz...-wrapperR/bin/hello (self) > /gnu/store|/zc92ghli...-test/bin//hello (@PROG@) > /gnu/store| (original_store) > | > > Because the manifest entry used in the tests added in this patch enters the "else" case of `wrapped-package` (c.f. > guix/scripts/pack.scm:904) the index calculation strays and we get a non-directory mount point. I can make the test > pass by using a slightly longer name of "testing" for the file-union :) > > I don't think we can enforce a stricter match between the wrapper and target store item names to ensure their lengths > are the same, right? It seems like we maybe want to ignore @WRAPPED_PROGRAM@ and use only /proc/self/exe and > original_store to find the relocated store directory? A regex search might be too costly. We could use strstr to > search for the first occurrence of original_store, if we don't mind assuming that most people will probably not unpack > into $HOME/.guix/gnu/store/mine/packs/foo e.g. Good catch! This is embarrassing. Instead of searching for an occurrence of ORIGINAL_STORE, can’t we use the file name of the wrapper (as opposed to WRAPPED_PROGRAM) in the index calculation? Along these lines: