On Mon, 19 Nov 2018 at 14:33:42 +0100, Bill Allombert wrote:
> On Mon, Nov 19, 2018 at 08:46:49AM +0000, Simon McVittie wrote:
> > * /usr/lib/*/pari/pari.cfg and /usr/include/*/pari/paricfg.h contain
> > absolute paths /usr/bin/gzip, /usr/bin/zcat
> > * If pari invokes those commands (I assume it does, but I haven't actually
> > checked) then it will not work on non-merged-/usr systems, where
> > /bin/gzip and /bin/zcat exist, but /usr/bin/gzip and /usr/bin/zcat do not
>
> Is not merged system supposed to have a /usr -> / symlink ?
Yes, although the symlinks are the other way round (/bin is a symlink
to /usr/bin and so on). The point of recent merged-/usr efforts[1] is
to group together all the static, read-only directories that need the
same handling (/usr, /bin, /sbin, /lib*) into one directory, possibly a
separate filesystem mounted from the initramfs or bind-mounted read-only
into a container. Compiling on unmerged /usr and using on merged /usr
works OK, because of the symlinks you mentioned, but that's the opposite
of the situation in this bug report.
The problem case is when you compile on merged-/usr and use on
unmerged-/usr:
- compile time, on merged /usr: which(1) etc. can't guess whether /bin/foo
or /usr/bin/foo is meant to be canonical, because both exist and are
equivalent
- runtime, on unmerged /usr: only the canonical paths will work
(/bin/gzip good, /usr/bin/gzip bad; /usr/bin/dpkg good, /bin/dpkg bad)
so if the build system guessed wrong, the program doesn't work
(and it can't guess right without a long list of exceptions, because
some standard utilities are canonically in /usr/bin and some in /bin)
> > Patching Configure, config/locate
> > and/or config/paricfg.h.SH is probably easiest.
>
> I think the better fix would be to replace the absolute path by a
> relative path (i.e.just ZCAT="gzip -dc").
That seems a valid patch for this bug, yes (assuming nothing is relying
on ZCAT starting with an absolute path).
smcv
[1] The hurd-i386 port tried to do the opposite, making /usr a symlink to
/, but that has all the same pain points as merged /usr without its
advantages (because static/read-only files are still spread between
/bin, /sbin, /lib* and /share, and are hard to separate from /etc
which also needs to be on the root filesystem).
