Bug 1065563 - rpmbuild 4.11.2-1: Invalid version (double separator '-'): 20120211-x86-64
rpmbuild 4.11.2-1: Invalid version (double separator '-'): 20120211-x86-64
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-14 18:28 EST by Harald Reindl
Modified: 2014-04-08 21:01 EDT (History)
11 users (show)

See Also:
Fixed In Version: rpm-4.11.2-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-19 19:41:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2014-02-14 18:28:24 EST
i'm sorry about most likely gave karam (bodhi currently down to verify) after testing rpm and rpmbuild with MariaDB but not expecting that below in case of httpd/php packages

the relevant SPEC parts are

%define            mmn 20120211
%define            mmnisa %{mmn}-%{__isa_name}-%{__isa_bits}
Provides:          %{name}-mmn = %{mmn}
Provides:          %{name}-mmn = %{mmnisa}

___________________________________________________

[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bs httpd.spec 
error: line 49: Invalid version (double separator '-'): 20120211-x86-64: Provides:          httpd-mmn = 20120211-x86-64

[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bs php-pecl-imagick.spec 
error: line 16: Invalid version (double separator '-'): 20121212-x86-64: Requires:          php(zend-abi) = 20121212-x86-64

[root@buildserver64:~]$ rpm -qa | grep rpm | grep 4.11
rpm-python-4.11.2-1.fc20.x86_64
rpm-4.11.2-1.fc20.x86_64
rpm-build-4.11.2-1.fc20.x86_64
rpm-libs-4.11.2-1.fc20.x86_64
rpm-build-libs-4.11.2-1.fc20.x86_64
___________________________________________________

[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bs httpd.spec 
Wrote: /home/builduser/rpmbuild/SRPMS/httpd-2.4.7-5.fc20.20140215.rh.src.rpm

[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bs php-pecl-imagick.spec 
Wrote: /home/builduser/rpmbuild/SRPMS/php-pecl-imagick-3.1.2-4.fc20.20140215.rh.src.rpm

[root@buildserver64:~]$ rpm -qa | grep rpm | grep 4.11
rpm-4.11.1-7.fc20.x86_64
rpm-python-4.11.1-7.fc20.x86_64
rpm-build-4.11.1-7.fc20.x86_64
rpm-build-libs-4.11.1-7.fc20.x86_64
rpm-libs-4.11.1-7.fc20.x86_64
Comment 1 Panu Matilainen 2014-02-17 01:38:11 EST
This is neither a bug or a regression in rpm, its a new sanity check doing its job catching invalid version strings. '-' has a legal character in version or release, it can only be a separator between them. Strings like these cannot be correctly parsed into their (E)V(R) components so any dependencies on them would be mishandled one way or the other (by rpm, yum etc)

These are packaging bugs and should be filed separately on httpd and 
php-pecl-imagick.
Comment 2 Harald Reindl 2014-02-17 04:20:26 EST
this *is a regression* and you can hardly make that a error wihtin a stable release because that means *any* package in this dependecy chain has a problem sooner or later

> These are packaging bugs and should be filed 
> separately on httpd and php-pecl-imagick

and php itslef, any httpd-modules and any php-modules
go out and report them and explain why this happens unannounced
i do not care about fedora server packages and make my workarounds
Comment 3 Harald Reindl 2014-02-17 04:48:49 EST
> it can only be a separator between them. Strings like 
> these cannot be correctly parsed into their (E)V(R) 
> components so any dependencies on them would be mishandled 
> one way or the other (by rpm, yum etc)

that is not true as you can see below, building only httpd without "Provides: httpd-mmn = 20120211-x86-64" results in solved dependencies but failing transaction checks for already installed packages reqiure this one

and now imagine the build-chain httpd / httpd-extensions / php / php-modules
well, i solve that on my own because i do not need the x86-64 deps by using exclude=*.i686 on all machines

httpd-mmn = 20120211-x86-64 is needed by (installed) mod_security-2.7.7-2.fc20.20131231.rh.x86_64
httpd-mmn = 20120211-x86-64 is needed by (installed) mod_h264_streaming-2.2.7-19.fc20.20131231.rh.x86_64
httpd-mmn = 20120211-x86-64 is needed by (installed) php-5.5.9-2.fc20.20140206.rh.x86_64
Comment 4 Remi Collet 2014-02-17 05:02:01 EST
This sanity check is nice, but only in rawhide.

We obviously can't plan a mass-rebuild of http and php stack in stable release.
Comment 5 Jan Kaluža 2014-02-17 05:05:19 EST
Btw, We have fixed httpd related packages in the rawhide already some weeks ago when the packages started failing to build there because of this change, but we didn't expect that this change will happen also in stable releases...
Comment 7 Harald Reindl 2014-02-17 05:33:24 EST
now it get's funny, i have rebuilt my whole webstack (php, httpd and all modules/extensions) but on the developer machine:

Running transaction check
ERROR with transaction check vs depsolve:
httpd-mmn = 20120211-x86-64 is needed by (installed) mod_dav_svn-1.8.5-2.fc20.x86_64

which shows that "Strings like these cannot be correctly parsed into their (E)V(R) components" is not really true
Comment 8 Mamoru TASAKA 2014-02-17 05:42:27 EST
On stable branches, this is a regression on rpm.
Comment 9 Fedora Update System 2014-02-17 08:20:52 EST
gnome-shell-3.10.3-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gnome-shell-3.10.3-7.fc20
Comment 10 Adel Gadllah 2014-02-17 08:23:43 EST
(In reply to Fedora Update System from comment #9)
> gnome-shell-3.10.3-7.fc20 has been submitted as an update for Fedora 20.
> https://admin.fedoraproject.org/updates/gnome-shell-3.10.3-7.fc20

Sorry about that had the wrong bug number in the clipboard ...
Comment 11 Panu Matilainen 2014-02-17 11:20:32 EST
Similar build-breaking sanity checks get added to rpm(build) all the time, and nobody expected this one to be any different.

Because these packaging mistakes appear to be very wide-spread in Fedora we can certainly consider turning this into a warning for F19 and F20. But exposing a common packaging bug is not an rpm regression, please get your terminology straight.
Comment 12 Harald Reindl 2014-02-17 11:36:07 EST
> Similar build-breaking sanity checks get added to rpm(build) 
> all the time, and nobody expected this one to be any different

*no*

as example the sanity checks for changelog-dates started with warnings and anybody right in his mind fixed them, but it did not happen in "push and now everybody needs to go ahead and seek for cases where a Mon should have be a Tue in the changelog"

> we can certainly consider turning this into a 
> warning for F19 and F20

yes, that has to be *alaways* the first step so packagers have a chance to face future problems and the time to fix them - you can't push a update in a stable release and expect a unkown number of packagers jsut jumping around and fix the breakage

that's the same as PHP starts to deprectate functions, parameters and code which means "in the next release this is most likely a fatal error, now start to prepare for the upcoming changes"
Comment 13 Remi Collet 2014-02-17 12:20:04 EST
(In reply to Panu Matilainen from comment #11)

> we can certainly consider turning this into a warning for F19 and F20. 

Yes please.
Comment 14 Panu Matilainen 2014-02-17 12:36:07 EST
(In reply to Harald Reindl from comment #12)
> > Similar build-breaking sanity checks get added to rpm(build) 
> > all the time, and nobody expected this one to be any different
> 
> *no*

No? I wasn't arguing or asking for an opinion, I was stating a fact. There are at least two other new such sanity checks in 4.11.2 that would break the build if you were to hit them, and for a reason.

> 
> as example the sanity checks for changelog-dates started with warnings and
> anybody right in his mind fixed them, but it did not happen in "push and now
> everybody needs to go ahead and seek for cases where a Mon should have be a
> Tue in the changelog"

A garbage date in changelog is a wee bit different from a dependency which will match (or not) something entirely different than the packager intended. 

> > we can certainly consider turning this into a 
> > warning for F19 and F20
> 
> yes, that has to be *alaways* the first step so packagers have a chance to
> face future problems and the time to fix them - you can't push a update in a
> stable release and expect a unkown number of packagers jsut jumping around
> and fix the breakage
> 
> that's the same as PHP starts to deprectate functions, parameters and code
> which means "in the next release this is most likely a fatal error, now
> start to prepare for the upcoming changes"

For "mostly harmless" errors, such as the changelog thing, certainly. The case here happens to be such that ranged dependencies will almost certainly be mismatched, which is a good deal more serious issue.

That a new sanity check will trip up something somewhere is expected, but that we happened to have entire package stacks built around invalid dependency EVR's was not. 

And yes its not sane to rebuild big package sets for this in stable releases so we have little choice but to turn it into a warning for F19-20.
Comment 15 Harald Reindl 2014-02-17 13:05:24 EST
> A garbage date in changelog is a wee bit different from a dependency 
> which will match (or not) something entirely different than the 
> packager intended

yes, the garbage in the changelog doe snot really matter
a dependency hell does

the "entire package stacks built around invalid dependency EVR's was not" exists for many years, so you hardly can argue that there is now a pressure to force a invasive change from one moment to the next

> And yes its not sane to rebuild big package sets for this in 
> stable releases so we have little choice but to turn it into 
> a warning for F19-20

which is why i wrote the bugreport because i know the big picture of that isa-dependencies around the webstack well for years, i personally have no problem with such changes and rebuilt the whole webstack in my private repo today and "subversion" too for the sake of dependencies - the distribution as such can't handle this caused by multiple involved people on different stages of the dependecy-chain
Comment 16 Fedora Update System 2014-02-18 02:49:10 EST
rpm-4.11.2-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rpm-4.11.2-2.fc20
Comment 17 Fedora Update System 2014-02-18 02:50:28 EST
rpm-4.11.2-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2014-2498/rpm-4.11.2-2.fc19
Comment 18 Harald Reindl 2014-02-18 06:08:00 EST
thanks, confirmed, one reason more to start with warnings as now below - you get all of the related lines at once instead jump from one error to the next
____________________________________________________

[builduser@testserver:/rpmbuild/SPECS]$ rpmbuild -bs httpd.spec 
Fehler: line 49: Invalid version (double separator '-'): 20120211-x86-64: Provides:          httpd-mmn = 20120211-x86-64
____________________________________________________

[builduser@testserver:/rpmbuild/SPECS]$ rpmbuild -bs httpd.spec 
Warnung: line 49: Invalid version (double separator '-'): 20120211-x86-64: Provides:          httpd-mmn = 20120211-x86-64
Warnung: line 96: Invalid version (double separator '-'): 20120211-x86-64: Requires:          httpd-mmn = 20120211-x86-64
Warnung: line 108: Invalid version (double separator '-'): 20120211-x86-64: Requires:          httpd-mmn = 20120211-x86-64
Warnung: line 116: Invalid version (double separator '-'): 20120211-x86-64: Requires:          httpd-mmn = 20120211-x86-64
Warnung: line 126: Invalid version (double separator '-'): 20120211-x86-64: Requires:          httpd-mmn = 20120211-x86-64
Warnung: line 133: Invalid version (double separator '-'): 20120211-x86-64: Requires:          httpd-mmn = 20120211-x86-64
Erstellt: /home/builduser/rpmbuild/SRPMS/httpd-2.4.7-5.fc20.20140218.rh.src.rpm
Comment 19 Fedora Update System 2014-02-19 19:41:14 EST
rpm-4.11.2-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2014-04-08 21:01:11 EDT
rpm-4.11.2-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.