On Thu, 22 Oct 2026 at 12:12, Roshan Sivakumar via lists.openembedded.org
<[email protected]> wrote:
> RPM 4 generated dependencies with the external __find_requires /
> __find_provides generator, which OE disabled entirely via
> _use_internal_dependency_generator 0. RPM 6 removed that mechanism; for
> v6-format packages only the internal fileattr generators run.
>
I don't understand. What was enabled in rpm 4 and what was not? What ran
and what didn't? The above seems to say that rpm 4 used external generator,
which was disabled by oe, but then the disabling statement refers to
internal generator.
> rpm's script.attr generator therefore runs for the first time in OE
> builds. For every packaged executable whose first line is a #! shebang
> it emits an interpreter dependency. kernel-devsrc ships
> scripts/mksysmap (#!/bin/sed -f) as an executable, so its package gains:
>
> Requires: /bin/sed
>
> OE manages build and runtime dependencies explicitly through
> DEPENDS / RDEPENDS and does not want these. They break real use cases:
>
> - The interpreter path is taken verbatim from the shebang. A #!/bin/sed
> script requires /bin/sed, but under usrmerge the only provider
> (busybox) offers /usr/bin/sed. The literal paths never match and the
> package becomes uninstallable.
>
But if the script in a target package refers to /bin/sed, and the target
root filesystem is not providing that, then the problem is not with the
dependency checker, it's with the script and/or filesystem layout.
Disabling the check does not address that problem, it just sweeps it under
the carpet. Am I missing something? How does this work on Fedora for
example, which also uses usrmerge?
> - In the SDK the sole interpreter providers (busybox, coreutils, bash,
> perl) are deliberately banned by target-sdk-provides-dummy, so these
> auto-generated requires make -dev/-src packages uninstallable during
> do_populate_sdk ("nothing provides /bin/sed needed by kernel-devsrc").
>
This probably needs steps to reproduce, so we can better understand the
issue.
> - The requires are non-reproducible: they are only emitted when the
> interpreter is scanned from the shebang during packaging, so the same
> recipe can produce different packages between the reproducible A and
> B builds.
>
I also don't understand this. How does the non-reproducibility happen
exactly? Why would it produce different requires?
> This is the same class of regression already handled for the pkgconfig
> generator; see "rpm: disable the RPM 6 pkgconfig dependency generator".
>
There was also a concern during patch review that the checks that the
generator does are useful to catch missing runtime dependencies in recipes,
and disabling this would regress the packaging quality. Something like this
checker should be made generic (e.g. run in do_package, regardless of
specific packaging backend). How does this check work exactly, and where is
it implemented? Do we have an equivalent in do_package (I vaguely remember
that we do)? If there's an equivalent, then why it doesn't complain but the
rpm-specific check does?
This needs further investigation.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#248950):
https://lists.openembedded.org/g/openembedded-core/message/248950
Mute This Topic: https://lists.openembedded.org/mt/121881349/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
