Re: Update: rpm package for utmps, skalibs.

From: Laurent Bercot <>
Date: Mon, 01 Apr 2024 12:44:13 +0000

> file /usr/bin from install of execline- conflicts with file from package filesystem-3.18-6.fc39.x86_64
> file /usr/bin/cd from install of execline- conflicts with file from package bash-5.2.26-1.fc39.x86_64
> file /usr/bin/umask from install of execline- conflicts with file from package bash-5.2.26-1.fc39.x86_64
> file /usr/bin/wait from install of execline- 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
and "bash" packages should not exist. They are just never called - any
of "cd", "umask" or "wait" in a shell script calls sa shell builtin, and
*have to* be builtins - they cannot work when called as external tools.
only reason why these binaries exist is to comply with a broad statement
POSIX that every builtin must also be provided as an external tool, even
where it does not make sense.
  Red Hat-based distributions are the only ones that do this. Other ones
understood that these binaries are useless.

  But obviously you cannot remove these binaries unless you're the
and "bash" maintainer, so workarounds must be found.

  The best workaround is to use an alternatives system if available. I
know if rpm provides this. The idea is to offer execline as an
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
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
*before* /usr/bin in the default PATH, and install, or link, execline
there. This may be difficult to find, because /usr/bin is generally one
the first locations in PATH. If you cannot find this, then the only way
to install execline binaries in their own directory (e.g.
*and* add that directory to the default PATH of every user, before
which is a lot more invasive.

  (If there is no policy that forbids creation of subdirectories in /,
could consider building skaware with --enable-slashpackage, and adding
/command at the top of the user PATH. execline would have its binaries
/package/admin/execline/command, accessible via /command, nothing would
conflict with stuff living in FHS, and as long as /command is before
in PATH, things would work. That is what I do on my machines. But
most distributions can be pretty anal about /package and /command -
which is
hypocritical considering they have no problem with /media and /srv, but
a fight for another day - so it's doubtful you can do that.)

  If everything else fails, document somewhere that execline, *and*
that depend on execline, will not be usable unless that directory is
*at the top of* the PATH. It's not only about finding the binaries, it's
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

  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
is explicitly NOT correct. execline binaries aren't supposed to be
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

Received on Mon Apr 01 2024 - 14:44:13 CEST

This archive was generated by hypermail 2.4.0 : Mon Apr 01 2024 - 14:44:40 CEST