Description of problem: The current NEVRA in Fedora 8, Fedora 9 and Fedora 10 [1] do not follow the package naming guidelines for pre-release packages [2]. This causes a build failure in packages dependent on it, like gstreamer-plugins-base [3], with the configure script complaining that: [...] checking for THEORA... no configure: Requested 'theora >= 1.0alpha5' but version of theora is 1.0RC1 [...] This is because of a similar problem in the version present in %{_libdir}/pkgconfig/theora.pc. [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=557 [2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=1029874 Version-Release number of selected component (if applicable): libtheora-1.0beta2-3.fc8 to libtheora-1.0rc1-2.fc10 Expected results: The correct NEVRA should be something like: libtheora-1.0-0.3.beta2.fc8 to libtheora-1.0-0.9.rc1.fc10 Even better would be to have libtheora-1.0-2 in Fedora 9 and Fedora 10. If possible in Fedora 8 also.
This issue was discussed during the merge review [1] where it was decided to delay fixing the violation until it really became a problem. It has become a problem now. Adding this as a blocker against the review. ---- [1] https://bugzilla.redhat.com/show_bug.cgi?id=226048
The package version in the rpm headers is something which does not concern configure scripts, only package management. As for the version in the .pc files, we are not going to change that, changing that from the upstream versioning scheme (which I admit sucks) potentially causes nasty surprises all over the place. As most configure scripts probably are written to handle this properly. Also F-10's gstreamer-plugins-base, does have the libgsttheora.so, so this clearly is fixed either upstream or with a Fedora specific patch, closing as not a bug.
Hmm, ok so I see that this works in F-10 because when gst-plugins-base got build there this problem did not (yet) exist. Still patching the .pc file is not a good idea. gst-plugins-base upstream agrees and has a patch fixing their configure script to cope here: http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/configure.ac?r1=1.754&r2=1.755
(In reply to comment #2) > The package version in the rpm headers is something which does not concern > configure scripts, only package management. The entire argument of not fixing the NEVRA was based on the argument that we might soon have a 1.1 which will fix the 1.0 < 1.0rc1 situation. 1.1 is not available yet, so why not fix this once and for all?
(In reply to comment #3) > Hmm, ok so I see that this works in F-10 because when gst-plugins-base got > build there this problem did not (yet) exist. It succeeded because: 1.0beta3 >= 1.0alpha5 Now it fails because: 1.0RC1 <= 1.0
(In reply to comment #5) Sorry, typo. > Now it fails because: 1.0RC1 <= 1.0 Now it fails because: 1.0RC1 < 1.0alpha5
(In reply to comment #5) > (In reply to comment #3) > > Hmm, ok so I see that this works in F-10 because when gst-plugins-base got > > build there this problem did not (yet) exist. > > It succeeded because: 1.0beta3 >= 1.0alpha5 > Now it fails because: 1.0RC1 <= 1.0 (In reply to comment #6) > (In reply to comment #5) > > Sorry, typo. > > > Now it fails because: 1.0RC1 <= 1.0 > > Now it fails because: 1.0RC1 < 1.0alpha5 This makes no sense... 1.0RC1 (1.0 Release Candidate 1) should be > 1.0alpha5, unless I'm way offbase. Shouldn't the progression be: alpha < beta < RC < final ? Lyos Gemini Norezel
> This makes no sense... 1.0RC1 (1.0 Release Candidate 1) should be > 1.0alpha5, > unless I'm way offbase. The comparison is based on ASCII codes. Since ascii('R') < ascii('a'), 1.0RC1 < 1.0alpha5. See: http://koji.fedoraproject.org/koji/getfile?taskID=1029877&name=build.log > Shouldn't the progression be: alpha < beta < RC < final ? Semantically, yes. To reflect this in the version numbering we should use the pre-release naming guidelines. Right now, I am more concerned of the problem of broken upgrade paths where the package in Rawhide will appear to have a lesser NEVRA than the one in Fedora 9 or Fedora 10. I don't think we should just close this as NOTABUG so easily.
(In reply to comment #8) > Right now, I am more concerned of the problem of broken upgrade paths where the > package in Rawhide will appear to have a lesser NEVRA than the one in Fedora 9 > or Fedora 10. > > I don't think we should just close this as NOTABUG so easily. If you are really so concerned about this, then you could of course have actually checked if this is a problem or not before making alarming claims. (Hint: this is not a problem).
(In reply to comment #9) > If you are really so concerned about this, then you could of course have > actually checked if this is a problem or not before making alarming claims. There is really no reason to get so personal or sarcastic about this, and I did check before filing this bug and so far have backed what I have been saying with reason. Now that I look more closely at it, I find this whole situation a bit funny. Someone slipped in an epoch which took care of the upgrade path, but did not care to fix the broken NEVRA in the older stable releases. By the way, can we have an update to 1:1.0 for Fedora 9 and Fedora 10? > (Hint: this is not a problem). Practically, this is a problem in packages which want to say something like: BuildRequires: libtheora >= 1.0-0.4.alpha5 ... but has to use: BuildRequires: libtheora >= 1.0 Not a big problem, but a problem nevertheless.
The versioning in Rawhide violates the package guidelines again: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease libtheora-1.1beta2-1.fc12 should had been libtheora-1.1-0.1.beta2.fc12 or anything that will not require yet-another-epoch bump to fix the situation, and epoch inflation is Bad. Please consider fixing in rawhide (which would break upgrade paths in rawhide, but that;s expected), and/or at least document the specfile around the Release tag to avoid repeating this mistake too many times.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
People. Don't try to guess what rpm will do. Ask it. atropine:~% rpmdev-vercmp 1.1beta2-1 1.1.0-1 0:1.1.0-1 is newer No epoch needed. F-12 is at 1.1.0-1.
Adam, you are just lucky, that 1.1 was released as 1.1.0. :) (or maybe you forced this onto upstream to save the day? ;) Anyway, there is a reason we try to move non-numeric prerelease version info into the Release tag. We can't hope to be lucky every time or try to guess whether upstream will use minor/subminor versioning etc. The packaging guidelines give a rather safe way to deal with it.