On 02/17/2014 07:02 PM, Toshio Kuratomi wrote:
On Mon, Feb 17, 2014 at 10:56:14AM +0000, Joe Orton wrote:
On Mon, Feb 17, 2014 at 12:37:53PM +0200, Ville Skyttä wrote:
I don't think this calls for a mass rebuild or any kind of a rebuild
actually, nor should it be rawhide only. AFAIU this doesn't affect
runtime at all, only build time, and affected packages can be just
fixed at the same time if they need an update in affected releases in
the first place.
The new rpmbuild cannot build an httpd which will satisfy dependencies
of current Fedora packages. The new rpmbuild will force us to break the
existing ABI dependency for httpd, breaking compatibility with existing
and third-party packages. And all that breakage is for zero gain, with
a bunch of engineering time wasted.
This change is inappropriate for a F19/20 update IMO. Yes, we know the
deps are "wrong", but that was not hurting any Fedora users, and we've
fixed it properly for F21.
I think this depends on what rpm and yum are currently doing with the
dependencies. As Panu says here:
https://bugzilla.redhat.com/show_bug.cgi?id=1065563#c1 if "-" is used in
version or release then rpm and yum have to guess about what portion of hte
string is the version and which is the release.
If rpm/yum are doing the wrong thing in a large number of cases (there's
several ways it could be "wrong" -- one portion of the stack is parsing it
as Version: 20140215-x86 Release: 64 and another is parsing it as Version:
20140215 Release: x86-64; there's a manual version comparison somewhere
that's looking for something like httpd-mmn >= 20140215 which always
evaluates false because the Provides is evaluating to Version: 20140215-x86;
etc) then it can be effectively argued that the provides themselves need to
be fixed in the stable Fedora release. rpmbuild's refusal to build is
simply a helpful tool for showing where these broken Provides are present.
However, it could also be that over the course of time rpm and the software
built on top of it has evolved to make the same guess about where to separate
version-release in the ambiguous case. If that's the case then sure, rpm
could continue to allow the broken behaviour in stable releases and only
make the change in rawhide.
I'd leave it to Panu and the rpm team to let us know which of those
scenarios are true for the current code.
Rpm generally looks for separators in N(E)VR from right to left, so
requires/provides "httpd-mmn = 20140215-x86-64" gets parsed as:
Version: 20140215-x86
Release: 64
This will "work" only when the requires are equivalence tests on the
full string, which seems to be the case for httpd-mmn requires.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
