Re: [OE-core] [PATCH v4 3/7] classes-global/package_rpm.bbclass: Remove %pre and %postin for libc6

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2026-02-09 at 23:10 -0800, Robert Yang via lists.openembedded.org wrote:
> From: Robert Yang <liezhi.yang@windriver.com>
> 
> Fixed:
> $ bitbake core-image-full-cmdline:do_testimage
> %post(busybox-1.37.0-r0.x86_64_x32): execv(/bin/sh) pid 624
> error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
> 
> It is because busybox and libc6 depends on each other, busybox' elf files
> depends on libc6, and libc6's postin depends on busybox' /bin/sh, the do_rootfs
> works well is because dnf-native has set RPM_NO_CHROOT_FOR_SCRIPTS=1, but it
> would be failed for a fresh rootfs.
> 
> In rpm 4.20.1, it let the installed files' Requires win, so it installed
> busybox firstly, but in rpm 6.0.1, it let the postin's Requires win since
> postin would run immediately after the files are installed, this does make
> sense, so it installed busybox (which provides /bin/sh required by libc6'
> postin) firstly, then we got the errors. I couldn't find which commit made this
> change because a lot of files and functions are refactored during 4.20.1 and
> 6.0.0 (not .1), I also tried bisect, but failed because a lot of do_patch or
> do_configure/do_compile failures for each build.
> 
> For libc6's the postin is:
> 
>   #!/bin/sh
>   if [ x"$D" = "x" ]; then
>       if [ -x /sbin/ldconfig ]; then /sbin/ldconfig ; fi
>   fi
> 
> This doesn't make sense for lib6 since there is no /bin/sh or ldconfig when
> libc6 is not ready yet, so we can just remove libc6's postin to fix the
> problem.
> 
> And also remove the workarounds in oeqa/runtime/cases/dnf.py, they are not
> needed any more since the circular dependency is fixed.
> 
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>  meta/classes-global/package_rpm.bbclass | 6 ++++--
>  meta/lib/oeqa/runtime/cases/dnf.py      | 8 --------
>  2 files changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/meta/classes-global/package_rpm.bbclass b/meta/classes-global/package_rpm.bbclass
> index f4dd779a52..526ac57982 100644
> --- a/meta/classes-global/package_rpm.bbclass
> +++ b/meta/classes-global/package_rpm.bbclass
> @@ -421,12 +421,14 @@ python write_specfile () {
>          spec_preamble_bottom.append('')
>  
>          # Now process scriptlets
> -        if splitrpreinst:
> +        # The libc6 shouldn't have %pre or %post to avoid circular dependency
> +        libc6 = '%slibc6' % (d.getVar('MLPREFIX') or '')
> +        if splitrpreinst and splitname != libc6:
>              spec_scriptlets_bottom.append('%%pre -n %s' % splitname)
>              spec_scriptlets_bottom.append('# %s - preinst' % splitname)
>              spec_scriptlets_bottom.append(splitrpreinst)
>              spec_scriptlets_bottom.append('')
> -        if splitrpostinst:
> +        if splitrpostinst and splitname != libc6:
>              spec_scriptlets_bottom.append('%%post -n %s' % splitname)
>              spec_scriptlets_bottom.append('# %s - postinst' % splitname)
>              spec_scriptlets_bottom.append(splitrpostinst)

I'm not happy about coding a "libc6" reference into the generic package
class. It does make me wonder if there is a similar issue with musl for
example and we'd end up with a longer hardcoded list.

Could/shouldn't we just not add that postinst for libc6? You could for
example force the value of pkg_postinst:libc6 during the packaging
process and empty the postinst instead.

Also the commit message explains the problem with the postinst but not
really why the preinst is a problem? What does that contain which is
problematic?

Cheers,

Richard