RPM upgrade caveats going from a beta version to RC
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Sat, 7 Apr 2001, Lamar Owen wrote:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
Huh? I always thought that ASCII R was greater then b ... *confused* in
the future, would it help to have 7.2Beta? Or am I missing something? :)
The Hermit Hacker wrote:
On Sat, 7 Apr 2001, Lamar Owen wrote:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.Huh? I always thought that ASCII R was greater then b ... *confused* in
the future, would it help to have 7.2Beta? Or am I missing something? :)
R = 82
b = 98
so b comes after R, and `blank' comes before either!
Therefore 7.1 < 7.1RC < 7.1beta !
As I suggested in another mail, let us switch to using even minor
numbers for releases and odd ones for development:
That means the final release of 7.1 will be called 7.2. Bugfix releases
will then be 7.2.x. Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so on...
For current 7.1, the Debian releases are 7.1beta, 7.1cRC, 7.1final,
which is both cumbersome and confusing to those who are looking for
an exact match.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Do not be anxious about anything, but in everything,
by prayer and supplication, with thanksgiving, present
your requests to God. And the peace of God, which
transcends all understanding, will guard your hearts
and your minds in Christ Jesus." Philippians 4:6,7
Import Notes
Reply to msg id not found: MessagefromTheHermitHackerscrappy@hub.orgofSun08Apr2001030832-0300.Pine.BSF.4.33.0104080307230.81918-100000@mobile.hub.org | Resolved by subject fallback
The Hermit Hacker writes:
On Sat, 7 Apr 2001, Lamar Owen wrote:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.Huh? I always thought that ASCII R was greater then b ... *confused* in
the future, would it help to have 7.2Beta? Or am I missing something? :)
How about 7.2rc1, which is greater than 7.2beta1.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sun, 8 Apr 2001, Oliver Elphick wrote:
The Hermit Hacker wrote:
On Sat, 7 Apr 2001, Lamar Owen wrote:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.Huh? I always thought that ASCII R was greater then b ... *confused* in
the future, would it help to have 7.2Beta? Or am I missing something? :)R = 82
b = 98so b comes after R, and `blank' comes before either!
Therefore 7.1 < 7.1RC < 7.1beta !
As I suggested in another mail, let us switch to using even minor
numbers for releases and odd ones for development:That means the final release of 7.1 will be called 7.2. Bugfix releases
will then be 7.2.x. Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so on...
Not in this life time ... we are not going to move to a Linux-like
development cycle ... *groan*
The Hermit Hacker wrote:or development:
That means the final release of 7.1 will be called 7.2. Bugfix releases
will then be 7.2.x. Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so on...Not in this life time ... we are not going to move to a Linux-like
development cycle ... *groan*
Harrumph!!
Well, pick some scheme that gives a rational set of numbers for
distributions. The current one is only good for installation
by hand!
(Mind you, my other major package is progressing from -1.00 to 0,
so that -0.76 is followed by -0.75. Not that I recommend you to
follow _that_ example.)
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Do not be anxious about anything, but in everything,
by prayer and supplication, with thanksgiving, present
your requests to God. And the peace of God, which
transcends all understanding, will guard your hearts
and your minds in Christ Jesus." Philippians 4:6,7
Import Notes
Reply to msg id not found: MessagefromTheHermitHackerscrappy@hub.orgofSun08Apr2001092713-0300.Pine.BSF.4.33.0104080926380.81918-100000@mobile.hub.org | Resolved by subject fallback
On Sun, 8 Apr 2001, Oliver Elphick wrote:
The Hermit Hacker wrote:or development:
That means the final release of 7.1 will be called 7.2. Bugfix releases
will then be 7.2.x. Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so on...Not in this life time ... we are not going to move to a Linux-like
development cycle ... *groan*Harrumph!!
Well, pick some scheme that gives a rational set of numbers for
distributions. The current one is only good for installation by hand!
We do, we follow the scheme as used by ... the BSD camp :) Be thankful we
don't go all the way and use 7.2-RELEASE too :)
The Hermit Hacker wrote:
We do, we follow the scheme as used by ... the BSD camp :) Be thankful we
don't go all the way and use 7.2-RELEASE too :)
If we had 7.1-CURRENT, 7.1-RELEASE, and 7.1-STABLE, the versioning
comparision would be just fine -- better than now. As it stands, an
upgrade from 7.1beta6 to 7.1RC4 and from 7.1RC4 to 7.1 is in the eyes of
at least two packaging systems a downgrade.
However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1
< 7.1.0, I think (saying that without having tested it could be
dangerous.... :-)).
Although I must observe that if RPM used the system's locale in
determining version collation, 7.1RC4 would be greater than 7.1beta6 --
which collation breaks our indexing and our LIKE optimizations, and
breaks our regression tests. :-) But 7.1 would still be a downgrade
based on that.
Red Hat uses a different system for their betas -- which I'm not
necessarily advocating, just presenting:
The public RedHat beta, IIRC, for what may or may not become Red Hat 7.1
carried a version of 7.0.91.
But then again the Linux kernel did that as well, going from 0.13 or so
to 0.97 (and various pl numbers) before hitting 1.0.
And just _why_ are you so adversarial to the Linux version numbering?
After all, it's just another system..... (Rhetorical question -- I
already know the answer) :-)
Personally, I think the Linux versioning is overkill, and prefer the BSD
way of labeling versions. But that is just my personal opinion.
But even at that, the Linux and BSD versioning is designed more for
carrying concurrent STABLE and CURRENT versions -- we don't really have
_that_ much version overlap to deal with, do we? Debian does as much --
but it is again a matter of version concurrency -- we're not likely to
release a 7.1.0 then a 7.0.4 that fixes bugs in the STABLE branch,
whereas at one point Linux 2.0.39, a 2.2.x, and 2.4.0 were being
released concurrently. The same happens with FreeBSDand others -- but
not us.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Oliver Elphick wrote:
R = 82
b = 98
This is a very small problem of having capital R and lowercase b that I
believe can be taken into account in the development of 7.2.
As I suggested in another mail, let us switch to using even minor
numbers for releases and odd ones for development:
It's a Linux-ism that personally I don't like. You have to be familiar
with the project to understand that 8.3.3 is not better for general use
than 8.2.4 because 8.2 is "stable" and 8.3 is "development".
--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750
"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925
However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok
progression, as 7.1 < 7.1.0, I think (saying that without having tested it could be
dangerous.... :-)).
I like this 7.1.0, it would also help to clarify what exact version is at hand.
People tend to use shorthands like 7.1 to refer to any patch version (like 7.1.3).
Andreas
Import Notes
Resolved by subject fallback
Zeugswetter Andreas SB writes:
However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok
progression, as 7.1 < 7.1.0, I think (saying that without having tested it could be
dangerous.... :-)).I like this 7.1.0, it would also help to clarify what exact version is at hand.
People tend to use shorthands like 7.1 to refer to any patch version (like 7.1.3).
I like that. In fact, we almost shipped a 7.0.0 but it was switched back
at the last minute because that's how it always was. Perhaps the
objection is that a 7.1.0 would indicate that there will be a 7.1.1 bug
fix release, but let's not kid ourselves.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Lamar Owen writes:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
Btw., are you aware of the 'serial' tag to override the version guessing
mechanism?
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote:
Lamar Owen writes:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.Btw., are you aware of the 'serial' tag to override the version guessing
mechanism?
Yes, I am, actually. But it seems a broken way of dealing with it.
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning. I could progress from '7.1-0.1beta1.1' through
'7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.
Last time I looked at the documentation for the serial tag, its use was
strongly discouraged. But that _has_ been awhile -- maybe it could be
useful. But I would prefer the whole version numbering thingtobe fixed,
as the Debian packages have the same issue -- and I don't know if .deb
has an analog to Serial:.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen wrote:
Last time I looked at the documentation for the serial tag, its use was
strongly discouraged. But that _has_ been awhile -- maybe it could be
useful. But I would prefer the whole version numbering thingtobe fixed,
as the Debian packages have the same issue -- and I don't know if .deb
has an analog to Serial:.
We have epochs, that is, the package version is preceded by an integer
and a colon, which overrides every other part of the version and release
number. However, if I ever use an epoch, I will be stuck with epochs for ever;
so I don't want to start.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Is any one of you in trouble? He should pray. Is
anyone happy? Let him sing songs of praise. Is any one
of you sick? He should call the elders of the church
to pray over him...The prayer of a righteous man is
powerful and effective." James 5:13,14,16
Import Notes
Reply to msg id not found: MessagefromLamarOwenlamar.owen@wgcr.orgofWed11Apr2001163002EDT.3AD4BECA.6242DFE6@wgcr.org | Resolved by subject fallback
Oliver Elphick wrote:
Lamar Owen wrote:
as the Debian packages have the same issue -- and I don't know if .deb
has an analog to Serial:.
We have epochs, that is, the package version is preceded by an integer
and a colon, which overrides every other part of the version and release
number. However, if I ever use an epoch, I will be stuck with epochs for ever;
so I don't want to start.
RPM also has the epoch mechanism -- and it sounds just like what you
have just described. Not something I want to start using, either. It's
more like a 'super-major' version number than the RPM serial mechanism,
which works in a more broken fashion.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen writes:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
Couldn't this be fixed (in future releases) with rcX and BetaX? I believe
r > B.
len morgan
Import Notes
Resolved by subject fallback
Lamar Owen writes:
Yes, I am, actually. But it seems a broken way of dealing with it.
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning. I could progress from '7.1-0.1beta1.1' through
'7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.
Just name them
7.1betax
7.1rcx
7.1.0
7.1.1
etc.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote:
Lamar Owen writes:
Yes, I am, actually. But it seems a broken way of dealing with it.
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning. I could progress from '7.1-0.1beta1.1' through
'7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.
Just name them
7.1betax
7.1rcx
7.1.0
7.1.1
And I like that -- but that would be Marc's (and the core group)
decision to make not mine. If the current schema is continued, I can
work around it --but it would be nice if the version numbering could be
more packager-friendly. I have a real aversion to naming the RPM
version number differently from the main package version.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
"Len Morgan" wrote:
Lamar Owen writes:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.Couldn't this be fixed (in future releases) with rcX and BetaX? I believe
r > B.
or, for that matter, by betaX rcX. But we have still gone from rc4 to
nothing in the just-released 7.1, which is backward as far as packaging
systems are concerned.
$ dpkg --compare-versions 7.1 gt 7.1rc4 || echo BSD style does not work!
BSD style does not work!
Marc, _please_ make the next release greater than its betas!
As far as Debian is concerned, 7.1 will be known as 7.1release. Sigh...
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Be strong, and let your heart take courage, all you
who hope in the Lord." Psalm 31:24