When I generated spec for iron v0.6.0 I noticed that it has following BuildRequires:
iron
0.6.0
BuildRequires: (crate(mime_guess/default) >= 1.8.1 with crate(mime_guess/default) < 2.0.0)
We have only mime_guess v2.0.0-alpha.6 packaged and DNF was satisfied with this package providing dependency. It has:
mime_guess
2.0.0-alpha.6
crate(mime_guess/default) = 2.0.0~alpha.6
Use 2.0.0~ as the constraint clause?
2.0.0~
That means, we'd need to change all conditions we have in the spec files :/
Since we guarantee that we can't have more than one ~ in a row, adding ~ at the end of upper clause should be good. Also 1.0.0- is not valid semver, so we should be good with this solution.
~
1.0.0-
@jistone @hellcp @akien thoughts?
Metadata Update from @ignatenkobrain: - Issue assigned to ignatenkobrain
2.0.0~ seems reasonable.
It turned out to be more complicated due to 2 things:
2.0.0---beta
2.0.0---beta < 2.0.0--alpha
^2.0.0-beta
2.1.0-beta
2.0.0
beta
2.0.0-beta ≤ x ≤ 2.0.0 ≤ x (no pre-release) < 3.0.0
So it seems that 2.0.0~ won't solve the problem... I'm thinking how we can achieve this with rich deps (by doing exclusion of pre-release versions).
I'll post comment once I have some solution.
So here is what I have in mind. Probably easiest way to describe is to use libsolv testcase:
repo available 0 testtags <inline> #>=Pkg: a 1.0.0 1 noarch #>=Pkg: a 2.0.0~beta 1 noarch #>=Prv: a:prerelease = 2.0.0 #>=Pkg: a 2.1.0~alpha 1 noarch #>=Prv: a:prerelease = 2.1.0 #>=Pkg: b 1 1 noarch #>=Req: (a >= 1.0.0 + a < 2.0.0) #>=Pkg: b 1 2 noarch #>=Req: (a >= 1.0.0 + a < 2.0.0 - a:prerelease) #>=Pkg: b 2 1 noarch #>=Req: (a >= 2.0.0~alpha + a < 3.0.0) #>=Pkg: b 2 2 noarch #>=Req: ((a >= 2.0.0 + a < 3.0.0 - a:prerelease) | (a >= 2.0.0~alpha + a:prerelease = 2.0.0)) system x86_64 rpm poolflags implicitobsoleteusescolors solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes # ^1, apparently pulls 2.0.0~beta (OLD) job install pkg b-1-1.noarch@available result transaction,problems <inline> #>install b-1-1.noarch@available #>install a-2.0.0~beta-1.noarch@available nextjob # ^1, should not pull even 2.0.0~beta (NEW) job install pkg b-1-2.noarch@available result transaction,problems <inline> #>install b-1-2.noarch@available #>install a-1.0.0-1.noarch@available nextjob # ^2.0.0-alpha, apparently pulls 2.1.0~alpha (OLD) job install pkg b-2-1.noarch@available result transaction,problems <inline> #>install b-2-1.noarch@available #>install a-2.1.0~alpha-1.noarch@available nextjob # ^2.0.0-alpha, should not pull 2.1.0~alpha (NEW) job install pkg b-2-2.noarch@available result transaction,problems <inline> #>install b-2-2.noarch@available #>install a-2.0.0~beta-1.noarch@available
Hopefully it is self-explanatory. If not, let me know and I'll explain it.
Metadata Update from @ignatenkobrain: - Issue set to the milestone: None (was: 7)
I just noticed that we have a patch for this in Fedora: https://src.fedoraproject.org/rpms/rust-packaging/blob/rawhide/f/0001-Always-require-upper-bound-dependency-with-sign.patch
We should probably include this upstream for the next version, since it has worked well since it was introduced in Fedora.
I submitted a pull request with the patch.
Commit ea59cb2 fixes this issue
Login to comment on this ticket.