Re: [meta-virtualization] [PATCH 1/2] image-oci: call pm.update() before pm.install() in multi-layer package layers

[Bruce Ashfield <bruce.ashfield@gmail.com>]

Taken to master-next with two things worth flagging.

1) I reworded the commit message to capture historical context that
   only makes sense from the maintainer side: our own multi-layer
   test recipes use OCI_LAYER_MODE=multi with packages: layers and
   they build fine, so it wasn't obvious at first read why this bug
   didn't already burn us. Root cause turned out to be that
   image-oci.bbclass has three separate call sites resolving
   IMAGE_PKGTYPE with hardcoded defaults that disagree with each
   other (rpm/ipk/rpm), so our unpinned builds silently take the
   rpm path -- and dnf install refreshes repodata on demand, so the
   missing pm.update() was a no-op for us. Reproducing your ipk
   trace required someone to actually be using opkg, which we
   weren't. The reworded body walks through all of that so the next
   reader doesn't have to. Your Signed-off-by is preserved.

2) Two follow-up commits on top:

   * "image-oci: unify IMAGE_PKGTYPE default via oci_pkg_type()
     helper" -- collapses the three disagreeing defaults into one
     shared helper, defaulting to ipk to match oe-core's
     PACKAGE_CLASSES default. Nothing changes for anyone who was
     already pinning IMAGE_PKGTYPE.

   * "tests: assert multi-layer OCI blobs have real content, not
     just count" -- our existing multilayer test only checked
     len(layers) == 3, which happily passes on a fully-empty build.
     Adds a per-layer blob-size floor so a silent pm.install()
     failure fails the test the way it should have all along.

Thanks for finding this one. The 2/2 libgcc/libgcc-initial patch
I'm still working through; I'd like to reproduce it locally and
see whether the fix can be simpler than a full BB_TASKDEPDATA
mutation. I'll follow up on that thread separately.

Bruce