On 06/27/2013 08:12 AM, Kalev Lember wrote:
Hi Martin,
Definitely not a rpm bug. rpm's version comparison semantics are well
defined and 4.10.0 is strictly higher than 4.10.
Martin, Kai, and I have discussed itand have proposal consistent with yours.
I would say one of the 3 things should happen to fix this:
1) Build the latest nspr release not as version 4.10, but as 4.10.0
(As I understand it, it's a manually generated tarball from CVS, so
shouldn't be a problem to change the versioning scheme downstream.)
It's easy enough to repakage the nspr-4.10.tar.bz as nspr-4.10.0.tar.bz,
upload that to the it lookaside cache and adjust the version in
nspr.spec to match that. Very minor changes to the spec file
2) Build a nspr 4.10 update that changes the version in the .pc file
to match the rpm version, so that it's also 4.10
I considered taht and payed with it. Proposal 1) is simpler, at least
for the time being.
3) Change the nspr dep in xulrunner so that it's not autogenerated,
and just manually specify the minimum nspr version.
Autogenerated is often preferable to manual. Let the tools query the
sources and keep me out as a middle-man that could make mistakes.
In any case, can you talk to emaldonado (CC-d) and sort this out? We
should try to keep the core set of package in an installable state, and
xulrunner / nspr has been broken for a while now in rawhide.
I brought this up with the nss/nspr team upstream. Kai added a good
explanation for them and proposedchanging the naming scheme two use
three numbersalwaysas the long term solution. Until that is accepted and
implemented upstream option (1) is a good temporary solution. I'm
working on testing it right now. I should have it solved by day's end.
-Elio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
