Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version range dependency #159

Closed
ignatenkobrain opened this Issue Feb 19, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@ignatenkobrain
Copy link
Member

commented Feb 19, 2017

Coming from https://bugzilla.redhat.com/show_bug.cgi?id=1389871

Unfortunately, rich dependencies do not help with that as pointed in one of comments:

# rpm -i bar-1-1.fc25.remi.noarch.rpm 
error: Failed dependencies:
	((foo >= 2) and (foo <= 3)) is needed by bar-1-1.fc25.remi.noarch

# rpm -i foo1-1-1.fc25.remi.noarch.rpm 
# rpm -q --provides foo1
foo = 1
foo1 = 1-1.fc25.remi

# rpm -i foo4-4-1.fc25.remi.noarch.rpm 
# rpm -q --provides foo4
foo = 4
foo4 = 4-1.fc25.remi

# pm -ivh bar-1-1.fc25.remi.noarch.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:bar-1-1.fc25.remi                ################################# [100%]

Last command works, when we expect a way to disallow it.

The point why I raise it here is that in Rust packaging we are blocked by this, because each package has it's own version range which means you never can get multiple versions of same crate to be installed (because they are in Conflicts now).

@ignatenkobrain

This comment has been minimized.

Copy link
Member Author

commented Feb 19, 2017

Example from Rust world:

ripgrep: BuildRequires: crate(clap) >= 2.18.0
ripgrep: BuildConflicts: crate(clap) >= 2.19.0

rust-clap-devel: Requires: crate(vec_map) >= 0.6.0
rust-clap-devel: Conflicts: crate(vec_map) >= 0.7.0
rust-clap-devel: Requires: crate(clippy) >= 0.0.112
rust-clap-devel: Conflicts: crate(clippy) >= 0.0.113

Let's take a look for each of dependencies

rust-vec_map-devel: Requires: crate(serde) >= 0.6.0
rust-vec_map-devel: Conflicts: crate(serde) >= 0.7.0

rust-clippy-devel: Requires: crate(serde) >= 0.9.1
rust-clippy-devel: Conflicts: crate(serde) >= 0.10.0

So when you will try to build ripgrep, you will end up with conflict of crate(serde)

@ignatenkobrain

This comment has been minimized.

Copy link
Member Author

commented Feb 19, 2017

Let me show some example how would libsolv work with this:

repo system 0 testtags <inline>
repo available 0 testtags <inline>
#>=Pkg: ripgrep 0.4.0 1 src
#>=Req: crate(clap) >= 2.18.0 & crate(clap) < 2.19.0
#>=Pkg: rust-clap-devel 2.18.5 1 noarch
#>=Prv: crate(clap) = 2.18.5
#>=Req: crate(vec_map) >= 0.6.0 & crate(vec_map) < 0.7.0
#>=Req: crate(clippy) >= 0.0.112 & crate(clippy) < 0.0.113
#>=Pkg: rust-vec_map-devel 0.6.0 1 noarch
#>=Prv: crate(vec_map) = 0.6.0
#>=Req: crate(serde) >= 0.6.0 & crate(serde) < 0.7.0
#>=Pkg: rust-clippy-devel 0.0.112 1 noarch
#>=Prv: crate(clippy) = 0.0.112
#>=Req: crate(serde) >= 0.9.0 & crate(serde) < 0.10.0
#>=Pkg: rust-serde-devel 0.9.1 1 noarch
#>=Prv: crate(serde) = 0.9.1
#>=Pkg: rust-serde6-devel 0.6.0 1 noarch
#>=Prv: crate(serde) = 0.6.0
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job install pkg ripgrep-0.4.0-1.src@available
result transaction,problems <inline>
+install ripgrep-0.4.0-1.src@available
+install rust-clap-devel-2.18.5-1.noarch@available
+install rust-clippy-devel-0.0.112-1.noarch@available
+install rust-serde-devel-0.9.1-1.noarch@available
+install rust-serde6-devel-0.6.0-1.noarch@available
+install rust-vec_map-devel-0.6.0-1.noarch@available

It would install both rust-serde-devel and rust-serde6-devel.

@ffesti

This comment has been minimized.

Copy link
Contributor

commented Feb 23, 2017

Further examination yields that libsolv already supports a way of dealing with this: REL_WITH which is represented in libsolvs dependency language as "+" and we probably want to represent in RPM as "with".

The semantic of the with operator is both sides need to be matched by the same package. For ease of implementation nesting of "and" terms is not supported (as they would yield tuples of packages as solution). "or" clauses are suppoerted, though. "if" and "if" "else" clauses should be supported but this needs further investigation.

I have POC patch extending the rich deps parser in RPM to allow "with" and to check and reject "and" nested in "with" clauses. The - more complicated - part of actually checking if there is a single package matching is still missing though. In the patch "with" is treated like "and".

@Conan-Kudo

This comment has been minimized.

Copy link
Member

commented May 25, 2017

@ignatenkobrain ignatenkobrain added this to the 4.14.0 milestone Aug 1, 2017

@ignatenkobrain

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

This got implemented as part of #299 \o/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.