[Bug 293817] ports-mgmt/pkg : pkgbase jail, pkg install ffmpeg pulls FreeBSD-clibs-lib32 when FreeBSD-base is enabled, but ffmpeg installs and runs without it if FreeBSD-base is disabled for the transaction

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293817

            Bug ID: 293817
           Summary: ports-mgmt/pkg : pkgbase jail, pkg install ffmpeg
                    pulls FreeBSD-clibs-lib32 when FreeBSD-base is
                    enabled, but ffmpeg installs and runs without it if
                    FreeBSD-base is disabled for the transaction
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: pkg@FreeBSD.org
          Reporter: paul.le.gauret@gmail.com
          Assignee: pkg@FreeBSD.org
             Flags: maintainer-feedback?(pkg@FreeBSD.org)

On a pkgbase-managed amd64 jail, `pkg install ffmpeg` pulls
`FreeBSD-clibs-lib32` when the `FreeBSD-base` repo is enabled.

Inside the jail, that transaction then fails while extracting the pkgbase lib32
package with errors like:

pkg: Fail to chflags /libc.so.7: Operation not permitted
pkg: Fail to chflags /librt.so.1: Operation not permitted
pkg: Fail to chflags /libsys.so.7: Operation not permitted
pkg: Fail to chflags /libthr.so.3: Operation not permitted
pkg: Fail to chflags /libexec/ld-elf32.so.1: Operation not permitted

However, if I perform the same `ffmpeg` install with `FreeBSD-base` unavailable
for that transaction, `ffmpeg` installs successfully, its dependencies still
include `gcc14`, `openblas`, `py311-numpy`, `Imath`, etc., and the resulting
`ffmpeg` binary works normally.

This suggests the issue is not a hard runtime requirement for lib32, but
install-time dependency resolution selecting `FreeBSD-clibs-lib32` on pkgbase
systems when `FreeBSD-base` is enabled.

Steps to reproduce:

1. Create a pkgbase-managed FreeBSD 15.0 amd64 jail.
2. Ensure both `FreeBSD-base` and a ports repo are enabled inside the jail.
3. Run `pkg install -n ffmpeg`.
4. Observe that the transaction includes `FreeBSD-clibs-lib32`.
5. Run the real install and observe extraction failure on base files with
`chflags ... Operation not permitted`.

For comparison:

1. Make `FreeBSD-base` unavailable for the transaction while keeping the ports
repo enabled.
2. Run `pkg install ffmpeg`.
3. Observe that `ffmpeg` installs successfully without `FreeBSD-clibs-lib32`.
4. Verify with `ffmpeg -version`, `ldd /usr/local/bin/ffmpeg`, and a simple
encode test. All of these succeed.

Actual result:

With `FreeBSD-base` enabled, `pkg` pulls `FreeBSD-clibs-lib32` and the install
fails in the jail during extraction/chflags handling.

Expected result:

`pkg install ffmpeg` on an amd64 pkgbase jail should not pull
`FreeBSD-clibs-lib32` unless it is actually required for the installed software
to function.

In this case, `ffmpeg` installs and runs without `FreeBSD-clibs-lib32` when
`FreeBSD-base` is not available to the solver, which suggests the lib32 pkgbase
dependency is not necessary for this transaction.

Additional information:

I traced the dependency chain far enough to show where lib32 becomes attractive
to the solver:

ffmpeg
-> libjxl
-> openexr
-> Imath
-> py311-numpy
-> openblas
-> gcc14

The installed package metadata for `gcc14` shows `MULTILIB` enabled and
declares `:32` shlib requirements such as:

libc.so.7:32
libdl.so.1:32
libm.so.5:32
librt.so.1:32
libthr.so.3:32

So the current behavior appears to be:

- pkg sees `:32` shlib requirements from `gcc14`
- on a pkgbase system with `FreeBSD-base` enabled, pkg resolves those via
`FreeBSD-clibs-lib32`
- in a jail, that becomes operationally problematic
- but the resulting application (`ffmpeg`) still works if lib32 is not brought
in

This may be either an overly aggressive dependency resolution choice in
`pkg`/pkgbase handling, or package metadata that causes unnecessary `:32`
requirements to be treated as mandatory in this context.

-- 
You are receiving this mail because:
You are the assignee for the bug.