Hi Kai,
Kai Liu
On 2022/01/19 Wed 06:58, Dan Čermák wrote:
Hi Kai,
Kai Liu
writes: Hi,
Say I have a project A which use project B as its build repository, while B use project C as its repository, and C use D and so on.
My understanding is A will eventually look for packages and projconf from B, C, D and down to the end of chain. Am I correct?
OBS will include all projects in path elements in your project configuration, e.g. if your repository is configured as follows: --8<---------------cut here---------------start------------->8--- <repository name="snapshot"> <path project="A" repository="Factory"/> <path project="Z" repository="test"/> <arch>x86_64</arch> </repository> --8<---------------cut here---------------end--------------->8---
then OBS will include A and Z in the buildroot. In addition to that, OBS will also include all projects from the last (iirc) path entry recursively (i.e. everything from Z) into your build root. However, it will not perform this recursive expansion this for all other entries (in this case A).
Hmm... why the last one is special. This looks quite unintuitive.
I don't know why it is the last one.
And I know this is a stupid question
Nope.
- what if there is only one path item for my project, will it be recursively included or not? As it's both the first and the last one :)
Since it is the last one, it will be recursively expanded.
If that's the case, how can I Stop that from happening? I.e. make A only looks for packages and projconf in B, not in C/D...
If A is not the last path entry, then that should not happen.
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*.
But most of the BuildRequires only point to a package name, without specifying any EVR. In such case if my paths provide different versions/releases of that package I should have seen "have choice" for versions. But I don't remember seen such case, all "have choices" I have seen are only about different packages can provide the same capability.
In most cases you will inherit the prjconf from openSUSE:Factory or some
other "base" project (e.g. Leap or SLE) and these have a *ton* of
`Prefer:` statements [1] in their project config, that shield you from
having to resolve these "have choice for" all the time.
Cheers,
Dan
Footnotes:
[1] ❯ osc meta prjconf openSUSE:Factory|grep 'Prefer:'|wc
669 1526 33270
--
Dan Čermák