added package-extension because of package-extension >= 1.0.0 (direct dep) added package-c because of package-extension:package-base-c >= 1.0.0 added package-a because of package-base-c:package-a >= 1.0.0 But the package-b in broken project clearly states BuildRequires: package-extension >= 1.0.0 BuildRequires: package-a >= 1.0.1 This remains "unresolvable" although package-a (1.0.1) is available from project base (1.0.1). This makes it pretty hard for us to make independant releases of these components base, extension, UI and broken project, although package dependencies and projects to resolve them are defined correctly using transitive project dependencies. What do you mean by "higher path"? The list in the project dependencies? <repository name="DebianJessie"> <path project="UI-1.0.1" repository="DebianJessie"/> <path project="extension-1.0.0" repository="DebianJessie"/> <arch>x86_64</arch> </repository> We defined the path for version 1.0.1 of UI and base first. Is this correct? Is there anything else how to get the scheduler to resolve the versioned dependency? Thanks Marcus
On October 26, 2016 at 4:27 PM Adrian Schröter <adrian@suse.de> wrote:
On Mittwoch, 26. Oktober 2016, 16:09:07 CEST wrote Marcus Klein:
Hi,
we have the following setup of projects with project dependencies in open buildservice: base (1.0.0) <- extension (1.0.0) base (1.0.1) <- UI (1.0.1) and extension (1.0.0), UI (1.0.1) <- broken project
We have a "package-b" in "broken project" that has build dependencies on a "package-a (1.0.1)" located in project "base (1.0.1)". Unfortunately the scheduler tries to resolve the build dependency sometimes with the "package-a (1.0.0)" located in project "base (1.0.0)". This leads to an "unresolvable" package state with message "nothing provides package-a >= 1.0.1".
All projects span several distributions including RHEL6, RHEL7 and Debian Jessie. This unresolvable state appears for all distributions.
Is the scheduler capable to resolve versioned dependencies with the available packages in both "base" projects and depending on the versioned dependency resolve it with the correctly versioned package-a?
In general OBS takes care about versioned deps, but it also takes the priority of used repositories into account. Means a higher path wins no matter what version may be in the lower path for a repository.
Without to know more about your setup, I can just recommend that you use the magic
# osc buildinfo -d .... | grep package-a
to find out why a specific package got used.
Thanks, Marcus
PS: we defined the build dependencies in the following way:
debian/control: Build-Depends: package-a (>= 1.0.1)
.spec: BuildRequires: package-a >= 1.0.1
--
Adrian Schroeter email: adrian@suse.de
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5 90409 Nürnberg Germany
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org