> From: [email protected] 
> <[email protected]> on behalf of Chen Qi via 
> lists.openembedded.org <[email protected]>
> Sent: Tuesday, February 10, 2026 18:53
> To: 정재윤/Task Leader/SW Platform(연)선행Platform개발실 Lightweight System Task 
> <[email protected]>; Richard Purdie <[email protected]>; 
> [email protected] 
> <[email protected]>
> Subject: Re: [OE-core] [PATCH] systemd: fix libsystemd LICENSE for multilib
>  
> Hi Jaeyoon,
> 
> I checked the related codes with PACKAGES_DYNAMIC in multilib.bbclass and 
> package.bbclass.
> I suspect that it's the do_split_packages function in package.bbclass that 
> needs to be fixed.
> This function may also need to use rename_package_variables on the 
> dynamically generated packages.
> You can refer to the multilib_virtclass_handler_postkeyexp function in 
> multilib.bbclass. Note that LICENSE is already in "PACKAGEVARS".
> Could you please check if the above method works?
> 
> Regards,
> Qi
> 

Hi Qi,

Thank you for your review, and yes, it works!
As you guessed, the package in trouble 'libsystemd' is being added to
'PACKAGES' later in do_split_packages. Calling rename_package_variables
after that fixes the issue.
By the way I found a side effect on libpam likely due to this fix:
| ERROR: lib32-libpam-1.5.3-r0 do_package: QA Issue: lib32-libpam: 
Files/directories were installed but not shipped in any package:
|   /usr/lib/security/pam_env.so
| Please set FILES such that these items are packaged. Alternatively if they 
are unneeded, avoid installing them or delete them within do_install.
| lib32-libpam: 1 installed and not shipped files. [installed-vs-shipped]
I don't get why it fails for now. Will take a look a bit more and also
check if it's fine in other do_split_packages use cases.


Best regards,
---
Jaeyoon Jung
Software Platform Lab. / Corporate R&D / LG Electronics Inc.

> 
> ________________________________________
> 
> -----Original Message-----
> From: [email protected] 
> <[email protected]> On Behalf Of Jaeyoon Jung (LGE) 
> via lists.openembedded.org
> Sent: Tuesday, February 10, 2026 5:04 PM
> To: Richard Purdie <[email protected]>; 
> [email protected]
> Subject: Re: [OE-core] [PATCH] systemd: fix libsystemd LICENSE for multilib
> 
> > From: Richard Purdie <[email protected]>
> > Sent: Tuesday, February 10, 2026 17:33
> > To: 정재윤/Task Leader/SW Platform(연)선행Platform개발실 Lightweight System
> > Task <[email protected]>; [email protected]
> > <[email protected]>
> > Subject: Re: [OE-core] [PATCH] systemd: fix libsystemd LICENSE for
> > multilib
> >  
> > On Tue, 2026-02-10 at 14:41 +0900, Jaeyoon Jung (LGE) via 
> > lists.openembedded.org wrote:
> > > From: Jaeyoon Jung <[email protected]>
> > >
> > > Prepend ${MLPREFIX} to LICENSE for libsystemd.
> > >
> > > Signed-off-by: Jaeyoon Jung <[email protected]>
> > > ---
> > >  meta/recipes-core/systemd/systemd.inc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/systemd/systemd.inc
> > > b/meta/recipes-core/systemd/systemd.inc
> > > index daf37060d7..80a527dd25 100644
> > > --- a/meta/recipes-core/systemd/systemd.inc
> > > +++ b/meta/recipes-core/systemd/systemd.inc
> > > @@ -11,7 +11,7 @@ elaborate transactional dependency-based service
> > > control logic. It can \
> > >  work as a drop-in replacement for sysvinit."
> > >  
> > >  LICENSE = "GPL-2.0-only & LGPL-2.1-or-later"
> > > -LICENSE:libsystemd = "LGPL-2.1-or-later"
> > > +LICENSE:${MLPREFIX}libsystemd = "LGPL-2.1-or-later"
> > >  LIC_FILES_CHKSUM =
> > > "file://LICENSE.GPL2;md5=c09786363500a9acc29b147e6e72d2c6 \
> > >                      
> > > [[file://LICENSE.LGPL2.1;md5=be0aaf4a380f73f7e00b420a007368f2"]file://LICENSE.LGPL2.1;md5=be0aaf4a380f73f7e00b420a007368f2]file://LICENSE.LGPL2.1;md5=be0aaf4a380f73f7e00b420a007368f2"]file://LICENSE.LGPL2.1;md5=be0aaf4a380f73f7e00b420a007368f2"
> > >  
> >
> > The commit message doesn't explain why.
> >
> > In most cases the code should automatically handle MLPREFIX. Are there
> > other similar issues elsewhere and should we be fixing something in
> > the multilib class extension code instead?
> >
> > Cheers,
> >
> > Richard
> 
> Yes, we have one in our meta layer that performs a check a bit deeper on 
> LICENSE for each package and it ends up with falling back to LICENSE with no 
> per-package override.
> It's also an option for us to fix ours but I thought that a hardcoded 
> per-package override like this should also take account into multilib, like 
> other LICENSE:${PN} cases.
> 
> 
> Best regards,
> ---
> Jaeyoon Jung
> Software Platform Lab. / Corporate R&D / LG Electronics Inc.
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230988): 
https://lists.openembedded.org/g/openembedded-core/message/230988
Mute This Topic: https://lists.openembedded.org/mt/117733881/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to