On Tue, 2026-09-01 at 13:58 +0200, [email protected] wrote:
> I tried the do_install postfunc and it breaks packagegroups.
>
> packagegroup.bbclass does "deltask do_install" but keeps do_package, and
> a deleted task never runs its postfuncs. So with
> LICENSE_CREATE_PACKAGE=1 add_package_and_files() still creates ${PN}-lic
> in perform_packagecopy, nothing fills it, and ALLOW_EMPTY is set for
> packagegroup packages - a silently empty package. Those -lic packages do
> have content today, as find_license_files() returns generic_<LICENSE>
> even with an empty LIC_FILES_CHKSUM. Packagegroups also deltask
> do_populate_sysroot, so they were never racy to begin with.
I suspect we should fix packagegroups differently, either disabling the
license packages, allowing them to be empty in that case or allowing
the postfunc to run. Might just be easiest to disable there.
> It is also wider than needed: do_install[postfuncs] has to be added
> unconditionally, so do_install's basehash changes for every recipe and
> sstate is invalidated from there downwards.
It would be a one off basehash change so I don't think this is a good
reason to base an architectural decision off.
> ${PKGD} avoids both - it is private to do_package, so the race is gone
> by construction, and it works for recipes without a do_install. It does
> stop staging license texts into recipe-sysroot, but that looks like the
> fix rather than a side effect, given the failure came out of
> sysroot_stage_all.
>
> Ok to keep ${PKGD}, or is there something about ${D} I am missing?
The intent has always been to have the packaged files and the sysroots
as similar as we can keep them, just to reduce complexity and potential
bugs. This is why I'm leaning to make this more in line with that
rather than making it worse...
Think about this from the other perspective of debugging where files
are coming from. They *supposed* to come from do_install and be in ${D}
. Even where there are differences between sysroots and ${D}, files are
pretty much always in ${D}. The current behaviour will therefore take
people by surprise. We have enough usability issues without creating
more differences without a good reason.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#244824):
https://lists.openembedded.org/g/openembedded-core/message/244824
Mute This Topic: https://lists.openembedded.org/mt/121030418/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
