On Mittwoch, 19. Januar 2022, 06:58:21 CET Dan Čermák wrote:
Hi Kai,
Kai Liu
writes: ... If that couldn't be done, may I know the strategy for OBS to look for packages in B/C/D...? Say my build requires a package P, B/C/D all have one, but might be with different version or release numbers. Is it picked in the nearest way (B first, only look in C if not found in B), or highest version way (which ever P in B/C/D has the highest version get picked)?
This is just from my observations, but afaik OBS will put everything into one build root and then search for all packages matching your NEVR (name-epoch-version-release) requirements. If it finds none, then it reports your package as unresolvable. If it finds *exactly* one, then it will build your package and if it finds more than one, then you'll get one of these "have choice for" errors, where you have to tell OBS which of the available packages you want *exactly*.
Choice errors only happen when multiple packages with different package names
provide the same required tag.
This is a situation where otherwise a random package would get installed
and therefore a not reproducible build environment would get created.
If multiple packages exist with the same name the one in the highest repository
path is usually used. It is not using the "newest" one based on NEVR, because
it could lead to a situation where builds may switch the repositories, because
the build counter is increasing.
And then you would debug issues caused by the fact that the build result in
the different repositories would not be the same. (eg. different feature
set or different dependencies)
However, for image building there is an option to enable this behaviour
nevertheless.
Use in kiwi files the tag
<!-- OBS-UnorderedRepos -->
and in Dockerfile
#!UnorderedRepos
to create this behaviour. See
https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.supported_f...
--
Adrian Schroeter