acpitool does exist. Going to layers.openembedded.org and searching for "pn:acpitool layer:meta-oe" (without quotes) finds it. Perhaps a glitch in the script or network.

While acpitool does exist, acptiool does not 🙃

Thanks @cottsay . I was staring right at that and couldn't see ti. ;)

Also thanks for writing the CI check, I just figured out how to run it on the command-line and am extending it for virtual support.

I think it supports virtual packages already, but definitely not @layer omission. Can you describe how that should behave?

The virtual targets are supposed to be a bit of a wildcard which seems opposed to the purpose of the check. The OE layerindex is meant to be inclusive and has obscure and unmaintained layers that I can't reasonably support. In another thread you had suggested that the documentation be updated to a list of "supported" OpenEmbedded layers.

What if I were to provide a list for the config.yaml of supported OE layers? Then we were to add something like this pseudocode to enumerate_layer_index_packages():

        provides = recipe.get('provides', '')

        for prov in provides.split():
            if not prov:
                continue
            if not layer in allowed_layers(): ## NEW
                continue ## NEW
            yield PackageEntry(f'{prov}', pv, recipe_url, pn, pn)  ## Modified to remove @{layer}

Where the intent is to permit virtual/foobar globally provided that a supported layer has a recipe that lists it in the provides?

I have two initial thoughts:

1. Can you still specify a virtual provision with @layer as well? Instead of modifying the PackageEntry, would it be more appropriate to yield an additional PackageEntry without the @layer?
2. Should we allow entries from layers other than the "blessed" layers if the rule specifies the @layer specifically?

It seems like you want to treat these virtual provisions differently from the actual package names, which we don't do for any other platforms. I'd just like to make sure we're properly reflecting the semantics of the package manager here. If they work the same way there, then we should follow that behavior.

We should consider whether curating a list of blessed layers is really what we want. Other platforms draw the line of "official" and "supported" packages on a per-repository basis. If the official OE layerindex is a mixed bag, it would make sense to re-draw the line in this context by declaring a list of blessed layers. If that's not really the case, maybe we should view the check as a measure of validity, and allow the person performing rosdep reviews to decide whether the rule (the layer in particular) is appropriate.

In terms of how this would look in config.yaml, I think this would need to be a modification of the !layer_index_url to pass additional data. Most of the other platforms take only a URL for specifying the repository, but !deb_base_url takes an additional string. We could do something similar here, too. Beyond that, I'd like to avoid adding any OE-specific configurations to the rosdep_repo_check subsystem as a whole. The other platforms color inside the lines and it would be a shame if we needed to break the abstraction to support this.

I spent some time digging into the original intent behind the OpenEmbedded support for rosdep. I verified that from the very beginning the intent wasn't to track packages, but to "map the ROS package names to the bitbake recipes". To your point, this means that we are already treating OpenEmbedded differently from any other platform as we aren't talking about package management.

This is important because the metadata in base.yaml gets used to generate recipes that specify dependencies on other recipes. For a variety of reasons the package names may not be the same. This means that we may encounter problems down the road if we start to try to use rosdep to install system dependencies (either on the host or target).

The document they wrote for the generation scheme mentions that " is only a hint: a recipe can be in different layers in different OpenEmbedded release series". For this reason, I think it is okay if we specify a recipe in one layer (eg. ffmpeg@openembedded-core) that may get overridden by another layer.

I prefer your suggestion of letting the reviewer do the check instead of trying to make a list of blessed layers. However, I do think that this puts extra responsibility on the reviewer to ensure that the layer in question is in good standing. It seems to imply that the reviewer must be familiar with OpenEmbedded. This is also something that will need to be monitored as recipes are removed and layers become unmaintained (but remain in the layerindex).

Regarding the virtual targets, it is the "right thing to do" but it may be unnecessary just for ocl-icd:

virtual/opencl-icd:
- opencl-icd-loader_2024.05.08.bb@meta-oe
- ocl-icd_2.3.2.bb@meta-oe
- imx-gpu-viv_5.0.11.p8.4-hfp@meta-fsl-arm
- imx-gpu-viv_6.4.11.p2.8-aarch32.bb@meta-freescale
- imx-gpu-viv_6.4.11.p2.8-aarch64.bb@meta-freescale
- ocl-icd_2.2.11.bb@meta-refkit-computervision
- rockchip-libmali.bb@meta-orangepi-r1plus

The alternatives are specific to a board that we aren't actively supporting or testing with. Since oci-icd is in meta-oe and matches the one used in Ubuntu, I can resubmit using ocl-icd@meta-oe instead of virtual/opencl-icd.

Adding support for virtual targets becomes more important when I try to get Gazebo / Ignition listed. I will have to revisit this discussion then when I have more context to work with.

Thanks for the help! I will work to revise the commit and update the PR once I have moved box2d, range-v3, xsimd, xtensor from meta-ros2-* into meta-ros2.