Hi there,
I’m exploring the design space for a graphics-core22 provider, and I’ve run into what seems like an easily-fixed limitation of snapcraft’s USN handling.
Specifically: it would be convenient and safer to statically link LLVM into the Mesa build for a mesa-core22 provider; this avoids weirdness when a consumer snap also contains LLVM. This can be accomplished by simply changing one of the configure options in the mesa packaging and rebuilding. So good, so far.
But now my understanding is that this snap would not receive USNs for mesa, as we’re now don’t have any mesa packages in stage-packages. However, the snap would be affected by any security bugs affecting the archive version of mesa, and rebuilding the snap would pick up any fixes from the archive, so it would be useful to receive USNs as if the snap contained the archive version of mesa.
Basically, I want to take the mesa $ARCHIVE_VERSION source package, patch it and build it, but also have libgl1-mesa=$ARCHIVE_VERSION in primed-stage-packages in the manifest.yaml.
I think you could bodge something up with a local snapcraft plugin - build the package, create a local repository, and use that local repository as PLUGIN_STAGE_SOURCES to pull stage-packages from that local repository.
It would be simpler if I could just explicitly add a package=$VERSION item to the manifest.yaml, though. There doesn’t seem to be any current mechanism to do that, but maybe it’s a sensible addition?