Red Hat Bugzilla – Bug 158859
alsa rcX packages will require epoch bump when 1.0.9 is released
Last modified: 2007-11-30 17:11:06 EST
Description of problem:
currently alsa-lib and friends are packaged with a version string of 1.0.9rcX.
When alsa 1.0.9 get released and packaged it will be rpm-older that 1.0.9rcX
thus requiring an epoch bump (bad!)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install 1.0.9rcX
2. Wait until 1.0.9 gets released
3. Package 1.0.9 w/o epoch bump
4. Package will not be upgraded
current alsa packages are rpm-newer than upcoming release
rcX packages should be rpm-older than 1.0.9-1
Since this currently only affects rawhide and test releases, please consider
changing the versioning to -1.0.9-0.rcX or similar before the release of FC4.
alsa 1.0.9 was just released. Please consider inclusion in FC4, or an early
update. Please avoid using epochs if possible, thanks!
(Upgrades from test release/rawhide would be busted w/o epochs, but that has
been discussed as being acceptable on fedora-devel)
New packages are 1.0.9rf (release final) + release number...
Same thing happened with 1.0.10. Please remove the rf tag before the release,
With 1.0.11rc<N>, please use as a version 1.0.11 and place the rc<N> in the
Martin, for future reference please read and follow the "Pre-Release Packages"
section of the package naming guidelines. This will allow us to avoid
unnecessary Epoch inflation or other ugly hacks like this "rf" thing in the future.
alsa-lib-1.0.10rc damage is already done with the Test1 release. IMHO, it is
wrong to simply "fix" it now as Axel suggests and everyone will not be able to
automatically upgrade into the newer package. Please just avoid this problem in
the future when alsa-lib goes increments into the next rc version.
(In reply to comment #4)
> alsa-lib-1.0.10rc damage is already done with the Test1 release. IMHO, it is
> wrong to simply "fix" it now as Axel suggests and everyone will not be able to
> automatically upgrade into the newer package.
That implies that there is now a guarantee for upgrades through testing and/or
rawhide series? I'd be glad if this is the case. And yes, we would have to live
with any versioning bugs, then. :/
IMHO there is still the "upgrades from test releases to gold releases are not
supported" clause, if this is the case, then please do fix it. Another half year
of broken alsa versions is ugly. Note that any alsa dependent package that will
depend on say alsa-lib >= 1.0.10a will need to carry on this versioning instead
and have funny dependencies like alsa-lib >= 1.0.10rfa.
I personally never liked our policy of removing stuff and counting on users to
manually fix their computers, but there are different opinions about this within
Red Hat. I *might* be okay with removing a package that has been in rawhide
only a few days in a non-important time (like 2 months ago). However in this
case it has unfortunately been broken for too long.
alsa-lib-1.0.10rc<N> entered rawhide exactly 2 months minus one day ago (28.09.05).
Upgrading from previouse versions (1.0.9[rf|rc]) will not break, so one
shouldn't count the 1.0.9 breakage.
Does that make it easier to revert this versioning? I agree that it is a better
goal to have guranteed upgradability in rawhide and/or testing, but as long as
it is not a Red Hat policy, it doesn't count to stick it on a special package case.
So since upgradability may be broken at several other package spots, please
consider at least abusing it to fix the alsa-lib/utils versioning. Otherwise it
will stick with FC5's live-frame and even worse perhaps RHEL5.
This isn't really THAT bad. And the likelihood of this being an issue for RHEL5
is almost nil. We only need to be sure to avoid this in the future.
If you see any similar issues like this popping up, please alert me immediately
via e-mail or Bugzilla CC and I'll take care of it.
I'll wait until 1.0.11 and then follow the oficial NVR format for FC.
new package is 1.0.11-1.rc2