Distags in rpm sort order (yes, versioning again ;)

[Axel Thimm]

Bringing up this topic again, since it was left unresolved.

I won't go into details again, about *why* a disttag is needed and why
it has to adhear to rpm internal sort algorithms. Please check the
following threads in doubt (and discuss the reasons there please, help
keeping this thread constructive this time ;):

http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551....
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263....

The bottom line is that distags are needed if one wants to create
packages for the same upstream sources but built for different
distributions. Disttags can then be embedded in the release tag to
ensure proper upgradability.

==================== Disttag schemes: pick one!

Here are the discussed schemes (some others exist with small
variations, e.g. fc instead of fdr, or no fdr tag at all, the
discussion is the same). Default versioning is (no cvs/beta, kernel
modules and special cases, leave that for another thread):

<name>-<upstream version>-<releasenumber><disttag><non sort
relevant suffixes, e.g. repoid>
e.g. simply
foo-1.2.3-4.<disttag>.johnsmith

disttag can be:
			A		B		C
Red Hat Linux 7.3	fdr0.7.3	rh7.3		rh7.3
Red Hat Linux 8.0	fdr0.8.0	rh8.0		rh8.0
Red Hat Linux 9		fdr0.9		rh9		rh9
Fedora Core 1		fdr1		rh9.1		1fdr
Fedora Core 2 test1	fdr1.95		rh9.1.95	1.95fdr

A) + consistent distid
   + future tagging will be self-explanatory
   + fits nicer into a general nameing scheme (e.g. not only RHL and
     FDR, but RHEL and non-RH could use, or allready do use the
     <disttag>:=<distid><distversion> idiom)
   - obfuscates RHL <= 9 rpm versioning
   - requires rebuilding of existing 3rd party repos for the sake of
     versioning.
   o requires a statement from redhat to allow calling RH 7.3 as FDR
     0.7.3 for instance, e.g. the "old" RHL product is officially
     conamed Fedora 0.something

B) + current practice for many repos offering rpms build form the same
     upstream sources for more than one distribution.
   + keeps current 3rd party repos from rebuilding all the old rpms
     just for reversioning (and users from redownloading the same rpms
     with a new name)
   - does not pertain the strict separation RHL <-> FDR, and may cause
     confusion.
   o A) is preferable, but B) may be a nice transition solution for
     existing installations.

C) + visually pertains separation of rh and fdr releases
   - is a kludgy workaround using rpm semantics present only after
     RHL9, thus breaking upgrading from RH8.0 and less (note that rpm
     errata for fixing this rpm bug and others are still not
     officially available)
   - number prefixing breaks when the preceding expression is numeric
     separated with dots or underscores, e.g.

	       foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr

     (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1")
     Using decimal release tags needs to be separately considered, but
     the fact is that they are being used often.
   - reverses order of distid and distversion
   - Variant "1fdr<version>" keeps order of distid and distversion,
     but breaks in all other ways above, as well as introducing an
     obfuscating decimal in the release tag.

I hope RH agrees to using A) or a variant thereof. In any case it
would be beneficial if an "official" solution could be blessed, so
that 3rd party repos don't have to reinvent their own
versioning.

Certainly many repos will start offering their packages (officially)
after FC1 is (officially) released, so there are only a few days left
...

In order to not molest users with forced downloads for reversioning
rpms for older RHL releases, I would suggest to use B) in a transition
phase for large rpms that do not need updating other than the
reversioning. After some time B) will have been phased out.

C) is not really an option. It will break more than it is intended to
salvage.

Also it would be nice to have rawhide versioning, e.g. immediately
after a release update fedora-release to the next test release
version or something below to indicate rawhide builds.

Thank you for your time.
-- 
Axel.Thimm(a)physik.fu-berlin.de

[Warren Togami]

Axel Thimm wrote:
>  
>  Certainly many repos will start offering their packages (officially)
>  after FC1 is (officially) released, so there are only a few days left
>  ... 
I could be wrong, but it is already too late to rename packages 
contained in FC1.  Just to be 100% clear I am soon posting my revised 
package naming counter-proposal for fedora.redhat.com.

Warren

[Axel Thimm]

On Thu, Oct 30, 2003 at 10:53:03PM -1000, Warren Togami wrote:
>  Axel Thimm wrote:
>  > Certainly many repos will start offering their packages
>  > (officially) after FC1 is (officially) released, so there are only
>  > a few days left ...
>  
>  I could be wrong, but it is already too late to rename packages
>  contained in FC1.  Just to be 100% clear I am soon posting my
>  revised package naming counter-proposal for fedora.redhat.com. 
I am not referring to FC1 itself (it is impossible to turn back time
;), but to the repos that want to offer rpms for it (and for "legacy"
RHL distros).

Of course, FC >= 1.95 should also consider the versioning scheme, it
is possible also less relevant for FC, as it will only seldomly have
to issue packages from the same upstream sources (just like RHL's
errata do).
-- 
Axel.Thimm(a)physik.fu-berlin.de

[Axel Thimm]

No comments from RH? Should every repository and its cat come up with
its own scheme creating more compatibility problems in the future?

On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote:
>  Bringing up this topic again, since it was left unresolved.
>  
>  I won't go into details again, about *why* a disttag is needed and why
>  it has to adhear to rpm internal sort algorithms. Please check the
>  following threads in doubt (and discuss the reasons there please, help
>  keeping this thread constructive this time ;):
>  
>  http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html
>  http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551....
>  http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263....
>  
>  The bottom line is that distags are needed if one wants to create
>  packages for the same upstream sources but built for different
>  distributions. Disttags can then be embedded in the release tag to
>  ensure proper upgradability.
>  
>  ==================== Disttag schemes: pick one!
>  
>  Here are the discussed schemes (some others exist with small
>  variations, e.g. fc instead of fdr, or no fdr tag at all, the
>  discussion is the same). Default versioning is (no cvs/beta, kernel
>  modules and special cases, leave that for another thread):
>  
>  <name>-<upstream version>-<releasenumber><disttag><non sort
> relevant suffixes, e.g. repoid>
>  e.g. simply
>  foo-1.2.3-4.<disttag>.johnsmith
>  
>  disttag can be:
>  			A		B		C
>  Red Hat Linux 7.3	fdr0.7.3	rh7.3		rh7.3
>  Red Hat Linux 8.0	fdr0.8.0	rh8.0		rh8.0
>  Red Hat Linux 9		fdr0.9		rh9		rh9
>  Fedora Core 1		fdr1		rh9.1		1fdr
>  Fedora Core 2 test1	fdr1.95		rh9.1.95	1.95fdr
>  
>  A) + consistent distid
>     + future tagging will be self-explanatory
>     + fits nicer into a general nameing scheme (e.g. not only RHL and
>       FDR, but RHEL and non-RH could use, or allready do use the
>       <disttag>:=<distid><distversion> idiom)
>     - obfuscates RHL <= 9 rpm versioning
>     - requires rebuilding of existing 3rd party repos for the sake of
>       versioning.
>     o requires a statement from redhat to allow calling RH 7.3 as FDR
>       0.7.3 for instance, e.g. the "old" RHL product is officially
>       conamed Fedora 0.something
>  
>  B) + current practice for many repos offering rpms build form the same
>       upstream sources for more than one distribution.
>     + keeps current 3rd party repos from rebuilding all the old rpms
>       just for reversioning (and users from redownloading the same rpms
>       with a new name)
>     - does not pertain the strict separation RHL <-> FDR, and may cause
>       confusion.
>     o A) is preferable, but B) may be a nice transition solution for
>       existing installations.
>  
>  C) + visually pertains separation of rh and fdr releases
>     - is a kludgy workaround using rpm semantics present only after
>       RHL9, thus breaking upgrading from RH8.0 and less (note that rpm
>       errata for fixing this rpm bug and others are still not
>       officially available)
>     - number prefixing breaks when the preceding expression is numeric
>       separated with dots or underscores, e.g.
>  
>  	       foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr
>  
>       (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1")
>       Using decimal release tags needs to be separately considered, but
>       the fact is that they are being used often.
>     - reverses order of distid and distversion
>     - Variant "1fdr<version>" keeps order of distid and distversion,
>       but breaks in all other ways above, as well as introducing an
>       obfuscating decimal in the release tag.
>  
>  I hope RH agrees to using A) or a variant thereof. In any case it
>  would be beneficial if an "official" solution could be blessed, so
>  that 3rd party repos don't have to reinvent their own
>  versioning.
>  
>  Certainly many repos will start offering their packages (officially)
>  after FC1 is (officially) released, so there are only a few days left
>  ...
>  
>  In order to not molest users with forced downloads for reversioning
>  rpms for older RHL releases, I would suggest to use B) in a transition
>  phase for large rpms that do not need updating other than the
>  reversioning. After some time B) will have been phased out.
>  
>  C) is not really an option. It will break more than it is intended to
>  salvage.
>  
>  Also it would be nice to have rawhide versioning, e.g. immediately
>  after a release update fedora-release to the next test release
>  version or something below to indicate rawhide builds.
>  
>  Thank you for your time. 


-- 
Axel.Thimm(a)physik.fu-berlin.de

[Axel Thimm]

On Mon, Nov 03, 2003 at 11:35:48AM +0100, Axel Thimm wrote:
>  No comments from RH? Should every repository and its cat come up
> with
>  its own scheme creating more compatibility problems in the future? 
Well, this thread is becoming old and boring and is like beating a
dead horse, so I am giving up ;)

While I personally think that scheme A (e.g. using fedora like
disttags for past RH releases) would solve the problems best, it only
makes sense to me, if that would become a standard, and not only
something atrpms follows.

Since neither RH nor any other repo really commented on this
(constructively that is ;), I guess it means repos will go wild with
supporting multiple RH/FC releases. I for my part will use scheme B
(numbering FC with something higher than rh9, e.g. rh9.1, similar to
Rex Dieter's suggestion a while back).

I wash my hands in innocence ;)

>  On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote:
>  > Bringing up this topic again, since it was left unresolved.
>  > 
>  > I won't go into details again, about *why* a disttag is needed and why
>  > it has to adhear to rpm internal sort algorithms. Please check the
>  > following threads in doubt (and discuss the reasons there please, help
>  > keeping this thread constructive this time ;):
>  > 
>  > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html
>  > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551....
>  > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263....
>  > 
>  > The bottom line is that distags are needed if one wants to create
>  > packages for the same upstream sources but built for different
>  > distributions. Disttags can then be embedded in the release tag to
>  > ensure proper upgradability.
>  > 
>  > ==================== Disttag schemes: pick one!
>  > 
>  > Here are the discussed schemes (some others exist with small
>  > variations, e.g. fc instead of fdr, or no fdr tag at all, the
>  > discussion is the same). Default versioning is (no cvs/beta, kernel
>  > modules and special cases, leave that for another thread):
>  > 
>  > <name>-<upstream version>-<releasenumber><disttag><non
> sort relevant suffixes, e.g. repoid>
>  > e.g. simply
>  > foo-1.2.3-4.<disttag>.johnsmith
>  > 
>  > disttag can be:
>  > 			A		B		C
>  > Red Hat Linux 7.3	fdr0.7.3	rh7.3		rh7.3
>  > Red Hat Linux 8.0	fdr0.8.0	rh8.0		rh8.0
>  > Red Hat Linux 9		fdr0.9		rh9		rh9
>  > Fedora Core 1		fdr1		rh9.1		1fdr
>  > Fedora Core 2 test1	fdr1.95		rh9.1.95	1.95fdr
>  > 
>  > A) + consistent distid
>  >    + future tagging will be self-explanatory
>  >    + fits nicer into a general nameing scheme (e.g. not only RHL and
>  >      FDR, but RHEL and non-RH could use, or allready do use the
>  >      <disttag>:=<distid><distversion> idiom)
>  >    - obfuscates RHL <= 9 rpm versioning
>  >    - requires rebuilding of existing 3rd party repos for the sake of
>  >      versioning.
>  >    o requires a statement from redhat to allow calling RH 7.3 as FDR
>  >      0.7.3 for instance, e.g. the "old" RHL product is officially
>  >      conamed Fedora 0.something
>  > 
>  > B) + current practice for many repos offering rpms build form the same
>  >      upstream sources for more than one distribution.
>  >    + keeps current 3rd party repos from rebuilding all the old rpms
>  >      just for reversioning (and users from redownloading the same rpms
>  >      with a new name)
>  >    - does not pertain the strict separation RHL <-> FDR, and may cause
>  >      confusion.
>  >    o A) is preferable, but B) may be a nice transition solution for
>  >      existing installations.
>  > 
>  > C) + visually pertains separation of rh and fdr releases
>  >    - is a kludgy workaround using rpm semantics present only after
>  >      RHL9, thus breaking upgrading from RH8.0 and less (note that rpm
>  >      errata for fixing this rpm bug and others are still not
>  >      officially available)
>  >    - number prefixing breaks when the preceding expression is numeric
>  >      separated with dots or underscores, e.g.
>  > 
>  > 	       foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr
>  > 
>  >      (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1")
>  >      Using decimal release tags needs to be separately considered, but
>  >      the fact is that they are being used often.
>  >    - reverses order of distid and distversion
>  >    - Variant "1fdr<version>" keeps order of distid and distversion,
>  >      but breaks in all other ways above, as well as introducing an
>  >      obfuscating decimal in the release tag.
>  > 
>  > I hope RH agrees to using A) or a variant thereof. In any case it
>  > would be beneficial if an "official" solution could be blessed, so
>  > that 3rd party repos don't have to reinvent their own
>  > versioning.
>  > 
>  > Certainly many repos will start offering their packages (officially)
>  > after FC1 is (officially) released, so there are only a few days left
>  > ...
>  > 
>  > In order to not molest users with forced downloads for reversioning
>  > rpms for older RHL releases, I would suggest to use B) in a transition
>  > phase for large rpms that do not need updating other than the
>  > reversioning. After some time B) will have been phased out.
>  > 
>  > C) is not really an option. It will break more than it is intended to
>  > salvage.
>  > 
>  > Also it would be nice to have rawhide versioning, e.g. immediately
>  > after a release update fedora-release to the next test release
>  > version or something below to indicate rawhide builds.
>  > 
>  > Thank you for your time.
>  
>  
>   


-- 
Axel.Thimm(a)physik.fu-berlin.de

[Fernando Lopez-Lezcano]

>  > No comments from RH? Should every repository and its cat come up
> with
>  > its own scheme creating more compatibility problems in the future?
>  
>  Well, this thread is becoming old and boring and is like beating a
>  dead horse, so I am giving up ;)
>   
Previously on this thread
>  > disttag can be:
>  >                       A               B               C
>  > Red Hat Linux 7.3     fdr0.7.3        rh7.3           rh7.3
>  > Red Hat Linux 8.0     fdr0.8.0        rh8.0           rh8.0
>  > Red Hat Linux 9       fdr0.9          rh9             rh9
>  > Fedora Core 1         fdr1            rh9.1           1fdr
>  > Fedora Core 2 test1   fdr1.95         rh9.1.95        1.95fdr
>
>  While I personally think that scheme A (e.g. using fedora like
>  disttags for past RH releases) would solve the problems best, it only
>  makes sense to me, if that would become a standard, and not only
>  something atrpms follows.
>  
>  Since neither RH nor any other repo really commented on this
>  (constructively that is ;), I guess it means repos will go wild with
>  supporting multiple RH/FC releases. I for my part will use scheme B
>  (numbering FC with something higher than rh9, e.g. rh9.1, similar to
>  Rex Dieter's suggestion a while back). 
I'm starting to use something similar in Planet CCRMA, I was previously
using:
  rh73 -> rh80 -> rh90
(so I can't really switch to rh7.3/rh8.0/rh9 at this point)
And now I'm rebuilding for FC1 with:
  rh73 -> rh80 -> rh90 -> rhfc1
Seems to work fine. 
-- Fernando

Final solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;))

[Axel Thimm]

On Fri, Nov 07, 2003 at 08:02:15PM -0800, Fernando Pablo Lopez-Lezcano wrote:
>  Previously on this thread
>  > > disttag can be:
>  > >                       A               B               C
>  > > Red Hat Linux 7.3     fdr0.7.3        rh7.3           rh7.3
>  > > Red Hat Linux 8.0     fdr0.8.0        rh8.0           rh8.0
>  > > Red Hat Linux 9       fdr0.9          rh9             rh9
>  > > Fedora Core 1         fdr1            rh9.1           1fdr
>  > > Fedora Core 2 test1   fdr1.95         rh9.1.95        1.95fdr 
>  I'm starting to use something similar in Planet CCRMA, I was
> previously
>  using:
>    rh73 -> rh80 -> rh90
>  (so I can't really switch to rh7.3/rh8.0/rh9 at this point)
>  And now I'm rebuilding for FC1 with:
>    rh73 -> rh80 -> rh90 -> rhfc1
>  Seems to work fine.  
Many 1000 thanks to Fernando. This is the best solution. I forgot that
rpm compares segment-wise and that longer stings are "newer".

I suggest all repos to use Fernando' suggestion, rhfc1, if they are
using rhXX for RHL. Please do use the same disttag for creating a
uniform versioning, .e.g.

	foo-1.2.3-4.rhfc1.at

Replace ".at" with your own repotag, none, if you don't want one, or
".fr", ".dag", ".che", ".ccrma", ".rb",
".kde4rh" (just suggestions).
Note: the repotag (contrary to the disttag) should not be part of the
rpm ordering, which is why it should come last.

Thank you Fernando, your brain was needed! This ******* thread was
rotting for a month and a half, without anyone (incluing me) using
their brains ...
-- 
Axel.Thimm(a)physik.fu-berlin.de

Best solution for disttags

[Axel Thimm]

Dear all,

It was mentioned to me and I just verified that "final solution" is a
reserved translated term for Nazi jargon at the end of the second
world war ("Endlösung").

There was no intention for any association with it, please change the
subject if you want to reply to the previous mail.
-- 
Axel.Thimm(a)physik.fu-berlin.de

Best solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;))

[Dag Wieers]

On Sat, 8 Nov 2003, Axel Thimm wrote:

>  On Fri, Nov 07, 2003 at 08:02:15PM -0800, Fernando Pablo
> Lopez-Lezcano wrote:
>  > Previously on this thread
>  > > > disttag can be:
>  > > >                       A               B               C
>  > > > Red Hat Linux 7.3     fdr0.7.3        rh7.3           rh7.3
>  > > > Red Hat Linux 8.0     fdr0.8.0        rh8.0           rh8.0
>  > > > Red Hat Linux 9       fdr0.9          rh9             rh9
>  > > > Fedora Core 1         fdr1            rh9.1           1fdr
>  > > > Fedora Core 2 test1   fdr1.95         rh9.1.95        1.95fdr
>  
>  > I'm starting to use something similar in Planet CCRMA, I was previously
>  > using:
>  >   rh73 -> rh80 -> rh90
>  > (so I can't really switch to rh7.3/rh8.0/rh9 at this point)
>  > And now I'm rebuilding for FC1 with:
>  >   rh73 -> rh80 -> rh90 -> rhfc1
>  > Seems to work fine. 
>  
>  Many 1000 thanks to Fernando. This is the best solution. I forgot that
>  rpm compares segment-wise and that longer stings are "newer". 
Hurray!


>  I suggest all repos to use Fernando' suggestion, rhfc1, if they
> are
>  using rhXX for RHL. Please do use the same disttag for creating a
>  uniform versioning, .e.g.
>  
>  	foo-1.2.3-4.rhfc1.at
>
>  Replace ".at" with your own repotag, none, if you don't want one, or
>  ".fr", ".dag", ".che", ".ccrma", ".rb",
> ".kde4rh" (just suggestions).
>  Note: the repotag (contrary to the disttag) should not be part of the
>  rpm ordering, which is why it should come last. 
I never intended to use the disttag as part of the EVR comparison. But I'm 
sure going to adapt DAR to work with the new scheme and use it by default.
It does make more sense to have the repotag at the end of the release.

Is there already a different repotag decided for fedora, fedora extras 
en/or fedora legacy ? Or is there no real gain to differentiate ?

Thanks Axel for making this a priority. It should have been decided more 
in advance, because taking corrective actions is always a waste of 
valuable time. I for one am glad to have delayed building for Fedora Core.
I already use the disttag 'rhel3' in the same manner.

Is there already a standard for the apt/yum -directory structure ? It 
would be nice to have a single syntax that repositories could move to.

I like 

	rhel3:		redhat/el3/i386 
	rhfc1:		redhat/fc1/i386

in the same line as 

	rh80:		redhat/8.0/i386
	rh90:		redhat/9/i386

Future versions would then become:

	rhel3.1:	redhat/el3.1/i386
	rhfc1.2:	redhat/fc1.2/i386

Could this subject be added to the naming convention proposal, together 
with the disttag ?

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]

Final solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;))

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 08 November 2003 01:33, Axel Thimm wrote:
>  Many 1000 thanks to Fernando. This is the best solution. I forgot
> that
>  rpm compares segment-wise and that longer stings are "newer".
>
>  I suggest all repos to use Fernando' suggestion, rhfc1, if they are
>  using rhXX for RHL. Please do use the same disttag for creating a
>  uniform versioning, .e.g.
>
>          foo-1.2.3-4.rhfc1.at
>
>  Replace ".at" with your own repotag, none, if you don't want one, or
>  ".fr", ".dag", ".che", ".ccrma", ".rb",
> ".kde4rh" (just suggestions).
>  Note: the repotag (contrary to the disttag) should not be part of the
>  rpm ordering, which is why it should come last.
>
>  Thank you Fernando, your brain was needed! This ******* thread was
>  rotting for a month and a half, without anyone (incluing me) using
>  their brains ... 
Why toss more text into there?  Is it _really_ needed?  Is not "1.at" rpm 
newer than "0.9.at" and newer than "rhl9.at" ?  WHy are we continuing
to 
put text where it really doesn't belong?   What's wrong with Warren's 
proposal that you feel it necessary to use something different?

- -- 
Jesse Keating RHCE MCSE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam		(www.mondorescue.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/rR+J4v2HLvE71NURAgMZAJ9J4BW7OQPOez7NhX2/gGNRjrK/IQCcDQOZ
> 5bdeCeT81OPrv3nEqF8V/e8=
> =eTcF
> -----END PGP SIGNATURE-----