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

Fri Nov 7 10:50:50 UTC 2003

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.html
> > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263.html
> > 
> > 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 at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031107/7063f61c/attachment.sig>