Bugzilla – Bug 1192011
Build service dependency resolution generates ambiguity
Last modified: 2021-11-14 15:56:00 UTC
For an image that has <!-- OBS-ExclusiveArch: x86_64 --> as architecture directive and that includes <package name="shim"/> the buildservice generates an "unresolvable" """ unresolvable: have choice for grub2-efi needed by shim: grub2-arm64-efi grub2-x86_64-efi """ however, since the arch is known the build service should be able to resolve the proper package to use, i.e. grub2-x86_64-efi
the grub2-*-efi packages are noarch packages. So it is not really defined which one to use. (and we do not want to add heuristics based on the package name). Not sure why these are noarch packages though, maybe this can be changed?
(In reply to Adrian Schröter from comment #1) > the grub2-*-efi packages are noarch packages. So it is not really defined > which one to use. (and we do not want to add heuristics based on the package > name). > > Not sure why these are noarch packages though, maybe this can be changed? I'm afraid we cannot ... They used to be arch specific package until a feature request by SUSE Manager to support building grub image on a host with different cpu architecture, most notably to the delivery of the grub PXE images. For eg, you could have an arm64 server setting up as PXE server to boot network clients with different target platform like x86. Through noarch package the grub modules to compose the target image are always available to a given host.
From my PoV this issue can be solved in two ways: #1 change `shim` to require the proper grub-platform for the architecture it is built for and not the generic `grub2-efi` (which was IMHO obsoleted by the noarch-move in FATE#326960). This may take a considerable amount of time, depending on whether repackaging of `shim` will require a new M$ signature or not. #2 amend the image definition, that pulls in `shim`, to also request the grub2-platform package (`grub2-x86_64-efi` in this case), to avoid the BS ambiguity. Robert, would #2 be a viable option?
I added the necessary package to the image description. And if that is the best we can do so be it. I do still consider the need to add the package to the image description as a work around. But we have other such things, the build service can also not resolve file dependencies for image builds and we add those packages into the image descriptions as well. If we think this cannot be fixed the issue can be closed.
Actually #1 is implemented in `shim` since Jan 2019 (at least in the development project) for FATE#326960 -- so this case was actually "fixed" early on! Robert, *where* did you find a `shim`-package, that still has that deprecated `grub2-efi` requirement?
SLES 15 SP2 image builds in IBS fell over.
Thanks for this clarification, Robert. The strange part is, that `shim-15+git47-3.3.1.x86_64.rpm` from SLE-15-SP2-Full-GM (on dist) already has the expected `grub2-x86_64-efi` dependency! Looking at the build logs might expose a different `shim`-package from a different source...