> file /usr/bin from install of execline-2.9.4.0-1.fc39.x86_64 conflicts with file from package filesystem-3.18-6.fc39.x86_64
> file /usr/bin/cd from install of execline-2.9.4.0-1.fc39.x86_64 conflicts with file from package bash-5.2.26-1.fc39.x86_64
> file /usr/bin/umask from install of execline-2.9.4.0-1.fc39.x86_64 conflicts with file from package bash-5.2.26-1.fc39.x86_64
> file /usr/bin/wait from install of execline-2.9.4.0-1.fc39.x86_64 conflicts with file from package bash-5.2.26-1.fc39.x86_64
Oh, Red Hat, never change.
The correct answer to this problem is that these binaries from the
"filesystem"
and "bash" packages should not exist. They are just never called - any
instance
of "cd", "umask" or "wait" in a shell script calls sa shell builtin, and
they
*have to* be builtins - they cannot work when called as external tools.
The
only reason why these binaries exist is to comply with a broad statement
in
POSIX that every builtin must also be provided as an external tool, even
those
where it does not make sense.
Red Hat-based distributions are the only ones that do this. Other ones
have
understood that these binaries are useless.
But obviously you cannot remove these binaries unless you're the
"filesystem"
and "bash" maintainer, so workarounds must be found.
The best workaround is to use an alternatives system if available. I
don't
know if rpm provides this. The idea is to offer execline as an
alternative
source for the cd, umask and wait binaries. If you build execline with
--enable-pedantic-posix (which you should do in this case), the binaries
provided by execline are fully compatible with the POSIX requirement,
and can
replace the default Fedora binaries entirely; they also provide actually
useful functionality when used in ways not explicitly covered by POSIX
(i.e.
when chain-loading, which is how they're used in execline scripts).
You may need to work with the filesystem and bash maintainers for this.
Short of that, the only possible workaround is to find a place that
appears
*before* /usr/bin in the default PATH, and install, or link, execline
binaries
there. This may be difficult to find, because /usr/bin is generally one
of
the first locations in PATH. If you cannot find this, then the only way
is
to install execline binaries in their own directory (e.g.
/var/lib/execline/bin)
*and* add that directory to the default PATH of every user, before
/usr/bin,
which is a lot more invasive.
(If there is no policy that forbids creation of subdirectories in /,
you
could consider building skaware with --enable-slashpackage, and adding
/command at the top of the user PATH. execline would have its binaries
in
/package/admin/execline/command, accessible via /command, nothing would
conflict with stuff living in FHS, and as long as /command is before
/usr/bin
in PATH, things would work. That is what I do on my machines. But
unfortunately,
most distributions can be pretty anal about /package and /command -
which is
hypocritical considering they have no problem with /media and /srv, but
that's
a fight for another day - so it's doubtful you can do that.)
If everything else fails, document somewhere that execline, *and*
packages
that depend on execline, will not be usable unless that directory is
added
*at the top of* the PATH. It's not only about finding the binaries, it's
about
making sure that the correct cd, umask and wait binaries are found; if a
binary from "filesystem" or "bash" is found instead, this will break
execline
scripts.
Note that what some distros did, i.e. putting the execline binaries in
/var/lib/execline/bin and adding a /usr/bin/execlineb wrapper that
prepends PATH
with /var/lib/execline/bin before executing
/var/lib/execlineb/bin/execlineb,
is explicitly NOT correct. execline binaries aren't supposed to be
accessible
only when called by execlineb; they're supposed to be accessible via the
default PATH, and some parts of skaware will break if they're not.
Putting them
in /var/lib/execline/bin is fine, but then /var/lib/execline/bin needs
to be
in the default PATH, and *before* /usr/bin, instead of being activated
by a
wrapper.
--
Laurent
Received on Mon Apr 01 2024 - 14:44:13 CEST