rpm bug 1065563 affecting httpd / php packages

[Panu Matilainen]

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 -