Re: [meta-virtualization][PATCH 6/7] vcontainer-bbmask.inc: allow meta-webserver/recipes-httpd

Hi Tim,

Small focused change, intent is clear. Two questions, one cleanup.

On Fri, May 29, 2026 at 18:31 -0700, Tim Orling wrote:
> Allow us to build nginx, apache2, etc. multiarch containers.
[...]
> +BBMASK += "meta-webserver/recipes-(?!httpd)"
[...]
>  BBMASK += "meta-filesystems/"
>  BBMASK += "meta-python/"
> -BBMASK += "meta-webserver/"

The mask is right and the regex correctly leaves recipes-httpd
parseable while keeping everything else under meta-webserver out.

A couple of things worth a follow-up:

  1. recipes-httpd contains both nginx and apache2 (and a couple of
     smaller recipes — hiawatha, lighttpd, monkey iirc). With this
     change apache2 also becomes parseable for the vcontainer distro,
     even though only nginx is used by 5/7. Is the apache2 inclusion
     intentional (to enable an app-container-apache2 follow-up later),
     or accidental?

     If accidental, tightening the regex to recipes-httpd/nginx- might
     be safer — fewer recipes pulled into parse keeps the dep graph
     smaller and avoids surprise cascades from apache2's deps.

  2. The companion entry in meta-virt-host.conf:

         BBFILE_PATTERN_IGNORE_EMPTY_<meta-webserver> = "1"
         (or similar variable name — the exact form is what
         meta-virt-host.conf uses for the other fully-masked layers)

     ...was added because meta-webserver used to be a fully-masked
     layer producing the "no recipes in this layer" warning. With this
     change, meta-webserver does parse at least one recipe (nginx),
     so the IGNORE_EMPTY entry is no longer needed and should be
     removed in this same commit. Otherwise it sits as dead config.

  3. Did you run `bitbake -g <container-image>` after this change to
     confirm the dep graph didn't pick up anything heavy you didn't
     expect? recipes-httpd's deps tend to be fairly contained, but
     it's worth a one-time check so we know the BBMASK fence is doing
     what we think it is.

The change itself is fine to apply as-is; (2) is the only thing I'd
ask be folded in before merge.

Bruce