On Wed, 27 Jul 2022 at 08:49:27 -0300, Antonio Terceiro wrote:
> > On Fri, 25 Feb 2022 at 15:26:51 -0800, Vagrant Cascadian wrote:
> > > The paths to various binaries, which differs on a usrmerge
> > > vs. non-usrmerge system, are embedded in rbconfig.rb:
> > >
> > > /usr/lib/x86_64-linux-gnu/ruby/3.0.0/rbconfig.rb
> > >
> > > CONFIG["EGREP"]·=·"/bin/grep·-E"
> > > vs.
> > > CONFIG["EGREP"]·=·"/usr/bin/grep·-E"
> >
> > If these CONFIG variables are used for something at runtime, then this
> > will become a practical problem as soon as Debian starts using merged-/usr
> > buildds.
>
> Those variables are read from config.status during the builds. Maybe
> this should be fixed centrally in autoconf instead?
autoconf is designed to support arbitrarily bad host OSs, including those
that are non-POSIX or otherwise defective, where the only fully-functional
grep might be /opt/sw/addons/misc/gnu/grep or something; so it has a
tendency to discover a known-good absolute path and save that.
This is great if you're building Ruby on an awful 1990s Unix machine
and the result of AC_PROG_EGREP will only be used during build, or if
it is used at runtime but you only plan to run the resulting Ruby binaries
on that same machine, but it goes wrong when facts about the build system
start to diverge from facts about the host system.
In this case, the fact that is different is the merged-/usr status
of the build system and the host system, but it could be almost anything.
The macros that Ruby uses to find these commands are probably AC_PROG_GREP,
AC_PROG_EGREP, etc., which are not explicitly documented to output an
absolute path (the documentation just says "whatever is chosen"), but
looking at their implementation, it seems they do: they are like
AC_PATH_PROG rather than AC_CHECK_PROG.
It's entirely possible that Ruby is not doing this deliberately, those
macros might well be a dependency for something else.
Is the Ruby build intentionally putting EGREP into rbconfig.rb for use by
some other component, or is it just populating that file with everything
that Autoconf happens to have discovered, on the off chance that it
might become necessary at some point? If the latter, then that seems
like it will cause unpredictable action-at-a-distance if Autoconf stops
needing to discover some particular thing (for instance if Autoconf's
maintainers decide that they are only going to support systems where
the first grep in PATH is POSIX.1-2001 compliant, and stop checking for a
possibly-better-quality grep elsewhere).
smcv
