Hi Alexander, I agree that disabling RPM's shebang-based dependency generator removes an existing feature, so I've dropped that approach. Instead, I've sent a minimal patch that declares the missing dependency directly: [email protected] | [PATCH] kernel-devsrc: add runtime dependency on sed<https://lists.openembedded.org/g/openembedded-core/topic/patch_kernel_devsrc_add/122008476>
This pulls in the full sed package which provides /bin/sed in usrmerge builds : Blaming openembedded-core/meta/recipes-extended/sed/sed_4.10.bb at master ยท openembedded/openembedded-core<https://github.com/openembedded/openembedded-core/blame/master/meta/recipes-extended/sed/sed_4.10.bb#L66>. Without this, populate_sdk task fails with "/bin/sed has no provider" error in builds where usermerge DISTRO_FEATURE is enabled. 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? I agree, will investigate further on this. In the meantime, I'd suggest we take this minimal RDEPENDS fix to unblock the immediate issue. Thanks, Roshan. ________________________________ From: Alexander Kanavin <[email protected]> Sent: Thursday, October 29, 2026 07:29 To: Roshan Sivakumar <[email protected]> Cc: [email protected] <[email protected]>; Sumanth Gavini <[email protected]>; Richard Purdie <[email protected]>; Paul Barker <[email protected]> Subject: Re: [OE-core][PATCH] rpm: disable the RPM 6 script interpreter dependency generator WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Thu, 22 Oct 2026 at 12:12, Roshan Sivakumar via lists.openembedded.org<http://lists.openembedded.org> <[email protected]<mailto:[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 (#249027): https://lists.openembedded.org/g/openembedded-core/message/249027 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]] -=-=-=-=-=-=-=-=-=-=-=-
