Bug 1065563

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.

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

> 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

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.

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...

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

On stable branches, this is a regression on rpm.

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

(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 ...

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.

> 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"

(In reply to Panu Matilainen from comment #11)

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

Yes please.

(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.

> 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

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

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

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

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.

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.