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

[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.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/20031103/e6b09aa9/attachment.sig>