On 8/18/2026 4:05 PM, Richard Purdie wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> On Tue, 2026-08-18 at 16:09 +0000, Sumanth Gavini via lists.openembedded.org
> wrote:
>> You are correct, and we should not have different dependencies between
>> packages based on the selected backend.
>>
>> In RPM 4, MERGEPERFILEDEPS = 1 resulted in __find_requires %{nil} and
>> __find_provides %{nil}, suppressing all autogenerated Requires and Provides.
>>
>> In RPM 6, use_internal_dependency_generator is no longer supported for
>> v6-format packages, so the fileattr-based generators always run. The
>> only way I see to suppress dependency generation is to set the
>> individual fileattr macros to %{nil}. We observed incorrectly generated
>> pkgconfig() dependencies on autobuilder and local builds, which led to
>> these changes.
>>
>> Should we also suppress all autogenerated Provides in RPM 6 to match the
>> RPM 4 behavior? If so, I'll need to identify the complete list of
>> fileattr-based provides generators that need to be disabled
>>
>> Thanks to Alex and Mathieu for their testing and support throughout this
>> upgrade.
>
> Yes, I think we need to disable them.
>
> Before we do that, I would like to understand what information this
> changes and whether there are dependencies we're going to miss out
> on that we really need to add to do_package.
>
> So there are two things to work out:
>
> - What information do we lose by turning off the rpm 4 rpmdep code in
> do_package? Do we need to add/find some of it differently?
>
> - What information do we lose by turning off the RPM 6 autogenerated
> dependencies and is there any of that we need to add separately to
> do_package somehow?
>
> Cheers,
>
> Richard
Hi Richard,
Thank you for the detailed questions. I went through the source code to
answer both fully.
---
Q1: What do we lose by turning off the RPM 4 rpmdep code in do_package?
Do we need to add/find some of it differently?
Nothing is lost and nothing needs to be added differently.
In RPM 4, the dep generation in rpmbuild was explicitly disabled:
package_rpm.bbclass (rpm_old):
line 661: --define '_use_internal_dependency_generator 0'
line 675: --define '__find_requires %{nil}'
line 676: --define '__find_provides %{nil}'
rpmbuild contributed zero file-based deps. The actual dep data came
from a separate tool — rpmdeps — which runs in package_do_filedeps,
defined in package.bbclass (shared across all backends):
package.bbclass:402
RPMDEPS = "rpmdeps --alldeps --define '__font_provides %{nil}'"
package.bbclass:404
python package_do_filedeps() → calls oe.package.process_filedeps()
meta/lib/oe/package.py:280
output = subprocess.check_output(shlex.split(rpmdeps) + pkgfiles)
rpmdeps uses the fileattr system internally (macros.in default:
_use_internal_dependency_generator = 1), so it generates ELF soname,
script interpreter and pkgconfig() deps. Results are stored in
FILERDEPENDS/FILERPROVIDES (package.py:1654) and written into the
RPM spec via get_perfile():
RPM4 package_rpm.bbclass:368
if not perfiledeps: ← True with default MERGEPERFILEDEPS=1
splitrdepends += get_perfile('RDEPENDS', pkg, d) # line 370
splitrprovides += get_perfile('RPROVIDES', pkg, d) # line 371
In RPM 6 this is unchanged and now unconditional:
RPM6 package_rpm.bbclass:303
splitrdepends += get_perfile('RDEPENDS', pkg, d)
splitrprovides += get_perfile('RPROVIDES', pkg, d)
Alongside this, two more backend-independent pipelines run unchanged:
package.bbclass:411 package_do_shlibs — objdump -p → OE package
name deps → RDEPENDS
package.bbclass:415 package_do_pkgconfig — .pc file parsing → OE
package name deps → RDEPENDS
All three pipelines are identical between RPM 4 and RPM 6 (confirmed
by diff of package.bbclass and package.py between the two directories —
only two unrelated lines differ in package.py, neither affecting deps).
---
Q2: What do we lose by turning off the RPM 6 autogenerated dependencies?
Is there any that we need to add separately to do_package?
Nothing is lost and nothing needs to be added to do_package.
In RPM 6, setting _use_internal_dependency_generator 0 is no longer
silently ignored — it is a hard build error for v6-format packages:
rpm/build/workspace/sources/rpm/build/rpmfc.cc:1618
if (!rpmExpandNumeric("%{?_use_internal_dependency_generator}")) {
if (fc->rpmformat < 6) {
rc = rpmfcApplyExternal(fc); // RPM4: allowed
} else {
rpmlog(RPMLOG_ERR,
_("External dependency generator is incompatible "
"with v6 packages\n"));
rc = RPMRC_FAIL; // RPM6: hard error
}
} else {
rc = rpmfcApplyInternal(fc); // fileattr system runs
}
So the only way to suppress deps in RPM 6 is per generator. The 12
fileattr generators are verified from:
rpm/build/workspace/sources/rpm/fileattrs/
Their status:
FULLY SUPPRESSED in v15:
- font.attr :__font_provides %{nil} (package_rpm.bbclass:601)
__font_requires is already %{nil} in the attr file
- sysusers.attr :__sysusers_path %{nil} (package_rpm.bbclass:606)
path=nil means no files match, entire generator disabled
__sysusers_requires also nil via
_use_weak_usergroup_deps 1
(package_rpm.bbclass:607, existed in RPM4 too)
PARTIALLY SUPPRESSED in v15:
- pkgconfig.attr : Requires: __pkgconfig_requires %{nil}
(package_rpm.bbclass:602)
Provides: still active → needs
__pkgconfig_provides %{nil}
NOT YET SUPPRESSED — needed in v16:
- elf.attr :Provides: libfoo.so.1 / Requires: libfoo.so.1
(duplicate of package_do_filedeps via rpmdeps — same
elfdeps tool; ipk/deb do not generate soname deps)
- script.attr : Requires: /bin/bash, /usr/bin/python3
(duplicate of package_do_filedeps via rpmdeps — same
script.req tool; ipk/deb do not generate these)
- pkgconfig.attr :Provides → pkgconfig(foo)
(duplicate of package_do_filedeps; ipk/deb do not
generate pkgconfig() deps)
- desktop.attr :Provides: application(), mimehandler(text/html)
(not in any OE pipeline; ipk/deb do not generate these)
- debuginfo.attr :Provides: debuginfo(build-id) = abc123
(not in any OE pipeline; ipk/deb do not generate these)
- metainfo.attr :Provides: metainfo(), metainfo(foo.xml)
(not in any OE pipeline; ipk/deb do not generate these)
- ocaml.attr :Provides/Requires: ocaml(Foo)
(not in any OE pipeline; ipk/deb do not generate these)
- rpm_lua.attr : Provides: rpm_lua(foo.bar)
(not in any OE pipeline; ipk/deb do not generate these)
- rpm_macro.attr :Provides: RPM macro file provides
(not in any OE pipeline; ipk/deb do not generate these)
- usergroup.attr: Provides: user(name), group(name)
(not in any OE pipeline; ipk/deb do not generate these)
For elf and script the suppression removes duplicates — the same deps
are already in the spec from package_do_filedeps via get_perfile().
For desktop, debuginfo, metainfo, ocaml, rpm_lua, rpm_macro and
usergroup, these are RPM-specific Provides that ipk/deb never generate.
Adding them to do_package would create exactly the backend inconsistency
you raised. They should be suppressed, not preserved.
v16 will add the following to package_rpm.bbclass:
cmd += " --define '__elf_requires %{nil}'"
cmd += " --define '__elf_provides %{nil}'"
cmd += " --define '__script_requires %{nil}'"
cmd += " --define '__pkgconfig_provides %{nil}'"
cmd += " --define '__desktop_provides %{nil}'"
cmd += " --define '__debuginfo_provides %{nil}'"
cmd += " --define '__metainfo_provides %{nil}'"
cmd += " --define '__ocaml_requires %{nil}'"
cmd += " --define '__ocaml_provides %{nil}'"
cmd += " --define '__rpm_lua_provides %{nil}'"
cmd += " --define '__rpm_macro_provides %{nil}'"
cmd += " --define '__usergroup_provides %{nil}'"
This restores the same zero auto-dep behaviour OE had with RPM 4,
keeping all three backends (rpm, ipk, deb) consistent.
Please review the above analysis, I am currently working on oe-selftest
failure(runtime_test.Postinst.test_failing_postinst).
Once the analysis looks good to you, I will include the above
suppression changes together with the selftest fix in v16.
--
# Sumanth Gavini
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243958):
https://lists.openembedded.org/g/openembedded-core/message/243958
Mute This Topic: https://lists.openembedded.org/mt/120783173/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
