Обсуждение: 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 mustbe forced to >> install with --oldpackage, as RPM does a simple strcmp of version >> numbers -- 7.1RC3 < 7.1beta1, forinstance. Just force it with >> --oldpackage if you have a 7.1beta RPM already installed. > >Huh? I always thought thatASCII 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
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 = 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... 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 soon... > >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
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
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 theDebian 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 singsongs of praise. Is any one of you sick? He should call the elders of the church to pray over him...The prayerof a righteous man is powerful and effective." James 5:13,14,16
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: > 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
>> 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
"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 (infuture 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