diff mbox series

oe-pkgdata-util: avoid glibc-locale being mapped out by glibc packages

Message ID 20241219092319.3800319-1-Qi.Chen@windriver.com
State New
Headers show
Series oe-pkgdata-util: avoid glibc-locale being mapped out by glibc packages | expand

Commit Message

ChenQi Dec. 19, 2024, 9:23 a.m. UTC 
From: Chen Qi <Qi.Chen@windriver.com>

oe-pkgdata-util's glob command will output different results depending
on whether glibc-locale is built or not. This in turn results in do_rootfs
error when multilib is enabled.

The error message is like below:

  No match for argument: lib32-glibc-locale-en-gb
  Error: Unable to find a match: lib32-glibc-locale-en-gb

Here are the steps to reproduce the issue:
1. Enable multilib and install a lib32 application by adding the following
   lines to local.conf:
   require conf/multilib.conf
   MULTILIBS ?= "multilib:lib32"
   DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32"
   IMAGE_INSTALL:append = " lib32-sysstat"
2. bitbake lib32-glibc-locale
   Note that people usually don't deliberately build lib32-glibc-locale,
   but they will do world build. And when so do so, the following step fails.
3. bitbake core-image-full-cmdline

The problem happened because do_rootfs will first form its own repo by finding
dependencies. glibc-locale will be brought in because of IMAGE_LINGUAS. But
lib32-glibc-locale will not be brought in. And in install_complementary,
oe-pkgdata-util will use its glob command to find all complememtary packages
for IMAGE_LINGUAS, such as "*-locale-en-gb". Then we get the above error.

glibc-locale has its own recipe and which to install into an image is
determined by IMAGE_LINGUAS. So let's not map any glibc packages out
to glibc-locale in oe-pkgdata-util.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 scripts/oe-pkgdata-util | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Ross Burton Jan. 8, 2025, 12:23 p.m. UTC | #1 
On 19 Dec 2024, at 09:23, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> 
> From: Chen Qi <Qi.Chen@windriver.com>
> 
> oe-pkgdata-util's glob command will output different results depending
> on whether glibc-locale is built or not. This in turn results in do_rootfs
> error when multilib is enabled.

The glob command is generically useful and not an implementation detail of the rootfs generation, so it shouldn’t be filtering the list of packages.  I’d absolutely expect the output to change depending on what packages were built, and if this is breaking rootfs generation then the rootfs generation logic needs to handle this case.

Ross
ChenQi Jan. 9, 2025, 2:17 a.m. UTC | #2 
Hi Ross,

The problem is that unlike other packages, glibc-locale and glibc are two recipes, and glibc-locale is specially handled via IMAGE_LINGUAS.

Regarding this glibc-locale issue, the rootfs generation logic is correct. Use the case I mentioned in commit message as an example, lib32-glibc-locale should not be installed. The rootfs logic ensures that and is correct. So maybe the glob command's logic is correct according to its original design, but it needs to be adjusted a little bit to fit the rootfs generation. Glibc-locale is the special case to handle.

I'm not sure if users will use this glob command manually, because they'll have to first construct a file to serve as an input. And that file is expected to contain actual package names. If they don't have some script to do that, they'll need to look at the deploy/rpm directory to construct the input file correctly.

I'm OK with any alternative solution. 

Regards,
Qi

-----Original Message-----
From: Ross Burton <Ross.Burton@arm.com> 
Sent: Wednesday, January 8, 2025 8:24 PM
To: Chen, Qi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] oe-pkgdata-util: avoid glibc-locale being mapped out by glibc packages

On 19 Dec 2024, at 09:23, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> 
> From: Chen Qi <Qi.Chen@windriver.com>
> 
> oe-pkgdata-util's glob command will output different results depending 
> on whether glibc-locale is built or not. This in turn results in 
> do_rootfs error when multilib is enabled.

The glob command is generically useful and not an implementation detail of the rootfs generation, so it shouldn’t be filtering the list of packages.  I’d absolutely expect the output to change depending on what packages were built, and if this is breaking rootfs generation then the rootfs generation logic needs to handle this case.

Ross
diff mbox series

Patch

diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util
index 44ae40549a..9fb7952c58 100755
--- a/scripts/oe-pkgdata-util
+++ b/scripts/oe-pkgdata-util
@@ -136,6 +136,10 @@  def glob(args):
                         logger.debug("%s is not a valid package!" % (pkg))
                         break
 
+                # we don't want glibc-locale to be mapped out by any glibc package, filter it out
+                if "glibc-locale" in mappedpkg:
+                    mappedpkg = ""
+
                 if mappedpkg:
                     logger.debug("%s (%s) -> %s" % (pkg, g, mappedpkg))
                     mappedpkgs.add(mappedpkg)