Re: rpm bug 1065563 affecting httpd / php packages
On 02/17/2014 07:02 PM, Toshio Kuratomi wrote: On Mon, Feb 17, 2014 at 10:56:14AM +, 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
Re: rpm bug 1065563 affecting httpd / php packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/02/2014 10:24, Reindl Harald a écrit : are such changes allowed within a stable release? https://bugzilla.redhat.com/show_bug.cgi?id=1065563 As lot of package are using a bad virtual provides / requires with a double dash in EVR, and as a mass rebuild is probably a very bad idea in stable release, I think this new check should only go in rawhide. Remi. P.S. php is not affected, only httpd, as this double-dash have be removed in the php 5.5 update, so in fedora 19. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMB300ACgkQYUppBSnxahiQEACcCetAykGvjJ0qD29Bqe8bbQ/d glgAnjmkZjya/LxR+wHe1OTJMScC+dog =fwvA -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
On Mon, Feb 17, 2014 at 12:07 PM, Remi Collet fed...@famillecollet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/02/2014 10:24, Reindl Harald a écrit : are such changes allowed within a stable release? https://bugzilla.redhat.com/show_bug.cgi?id=1065563 As lot of package are using a bad virtual provides / requires with a double dash in EVR, and as a mass rebuild is probably a very bad idea in stable release, I think this new check should only go in rawhide. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
Am 17.02.2014 11:37, schrieb Ville Skyttä: On Mon, Feb 17, 2014 at 12:07 PM, Remi Collet fed...@famillecollet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/02/2014 10:24, Reindl Harald a écrit : are such changes allowed within a stable release? https://bugzilla.redhat.com/show_bug.cgi?id=1065563 As lot of package are using a bad virtual provides / requires with a double dash in EVR, and as a mass rebuild is probably a very bad idea in stable release, I think this new check should only go in rawhide. 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. *no* look here to see why https://bugzilla.redhat.com/show_bug.cgi?id=1065563#c7 and the same will happen for *any* package built the same way, i can only speak about the few i am using yes, i am about rebuild subversion to get this solved because i have now changed all these Provides/Requires in my *private* webstack packages, but that shows it's not that simple you assume signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
On 02/17/2014 11:37 AM, Ville Skyttä wrote: On Mon, Feb 17, 2014 at 12:07 PM, Remi Collet fed...@famillecollet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/02/2014 10:24, Reindl Harald a écrit : are such changes allowed within a stable release? https://bugzilla.redhat.com/show_bug.cgi?id=1065563 As lot of package are using a bad virtual provides / requires with a double dash in EVR, and as a mass rebuild is probably a very bad idea in stable release, I think this new check should only go in rawhide. 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. Hmm, what is the recommended fix to affected EVRs which would allow fully transparent updates and upgrades from packages with broken EVRs? To replace - with _? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
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. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
On Mon, Feb 17, 2014 at 10:56:14AM +, 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. -Toshio pgpjADYu0Jmk_.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm bug 1065563 affecting httpd / php packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/02/2014 18:02, Toshio Kuratomi a écrit : 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. Yes the EVR is broken. But currently yum / rpm / createrepo parse this the same way, and so this issue have never hit fedora User. This issue only hits spacewalk / satellite (or RHN) users (which have a different parser for EVR). I think the panu's proposal to turn this into a warning in f19/f20 is the correct solution. Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCRIUACgkQYUppBSnxahhAiwCghrs7RJ7+rLIF9wEEx3A30FH3 FUUAoJUovq8hYGYqPy+du2SNMgIGLSJc =RiXS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
