Re: [PATCH] Remove incorrect special handling of /usr/libexec

On Mon, Aug 26, 2024 at 09:55:47AM +0200, Stefano Brivio wrote:

On Mon, 26 Aug 2024 16:39:01 +1000 David Gibson wrote:

...

The statement in the comment about /usr/libexec being only for running on other hosts simply isn't true, neither in practice nor according to the FHS spec[0].

I don't remember where I took that meaning of /usr/libexec from, I guess it's from some outdated packaging guidelines (Fedora? Kata Containers?). Sure, it makes sense to fix that.

...

Furthermore this logic didn't even handle it correctly, since it would only handle binaries _directly_ in /usr/libexec, not those in (explicitly FHS permitted) subdirectories under /usr/libexec.

So, this change breaks the two cases I needed to cover with this, which are /usr/libexec/kata-agent in general, and /usr/libexec/qemu-kvm on RHEL 9.

Huh.. why?

What does it fix?

I don't have a concrete case, but it would break anything where we're including this support binary, but the "front end" binary looks for it explicitly in /usr/libexec. Which I'd kind of expect to be most support binary cases, since by design /usr/libexec won't generally be in the PATH.

...

[0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

Signed-off-by: David Gibson --- mbuto | 8 -------- 1 file changed, 8 deletions(-)

diff --git a/mbuto b/mbuto index a2a8147..5e8ea9c 100755 --- a/mbuto +++ b/mbuto @@ -752,14 +752,6 @@ prog_add() { unset IFS [ -z "${__bin}" ] && err "Can't source ${1}"

- # Binaries in /usr/libexec are meant to run on other hosts only, so they - # can't reside in /usr/libexec on the target image. Move to /usr/bin. - if [ "$("${DIRNAME}" "${__bin}")" = "/usr/libexec" ]; then - __bindir="${wd}/usr/bin" - else - __bindir="${wd}$("${DIRNAME}" "${__bin}")" - fi - "${MKDIR}" -p "${__bindir}" "${CP}" --preserve=all "${__bin}" "${__bindir}"

-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson