Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158859 - alsa rcX packages will require epoch bump when 1.0.9 is released
Summary: alsa rcX packages will require epoch bump when 1.0.9 is released
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-lib
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-26 10:20 UTC by Axel Thimm
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-12 14:37:15 UTC


Attachments (Terms of Use)

Description Axel Thimm 2005-05-26 10:20:45 UTC
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):
1.0.9rcX

How reproducible:
always

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

Actual results:
current alsa packages are rpm-newer than upcoming release

Expected results:
rcX packages should be rpm-older than 1.0.9-1

Additional info:
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.

Thanks!

Comment 1 Axel Thimm 2005-05-27 17:24:49 UTC
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)

Comment 2 Martin Stransky 2005-05-30 16:04:30 UTC
New packages are 1.0.9rf (release final) + release number...

Comment 3 Axel Thimm 2005-11-26 19:56:56 UTC
Same thing happened with 1.0.10. Please remove the rf tag before the release,
thanks!

With 1.0.11rc<N>, please use as a version 1.0.11 and place the rc<N> in the
release field.

Comment 4 Warren Togami 2005-11-26 21:57:55 UTC
http://fedoraproject.org/wiki/PackageNamingGuidelines
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.


Comment 5 Axel Thimm 2005-11-27 19:59:46 UTC
(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.


Comment 6 Warren Togami 2005-11-27 20:10:54 UTC
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.


Comment 7 Axel Thimm 2005-11-27 21:41:53 UTC
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.


Comment 8 Warren Togami 2005-11-28 02:20:29 UTC
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.

Comment 9 Martin Stransky 2005-12-06 09:12:49 UTC
I'll wait until 1.0.11 and then follow the oficial NVR format for FC.

Comment 10 Martin Stransky 2006-01-12 14:37:15 UTC
new package is 1.0.11-1.rc2


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