Bug 158859 - alsa rcX packages will require epoch bump when 1.0.9 is released
alsa rcX packages will require epoch bump when 1.0.9 is released
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: alsa-lib (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-26 06:20 EDT by Axel Thimm
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-12 09:37:15 EST
Type: ---
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 Axel Thimm 2005-05-26 06:20:45 EDT
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 13:24:49 EDT
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 12:04:30 EDT
New packages are 1.0.9rf (release final) + release number...
Comment 3 Axel Thimm 2005-11-26 14:56:56 EST
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 16:57:55 EST
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 14:59:46 EST
(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 15:10:54 EST
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 16:41:53 EST
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-27 21:20:29 EST
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 04:12:49 EST
I'll wait until 1.0.11 and then follow the oficial NVR format for FC.
Comment 10 Martin Stransky 2006-01-12 09:37:15 EST
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.