Axel Thimm
2003-10-31 06:58:46 UTC
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.
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.
--
***@physik.fu-berlin.de
***@physik.fu-berlin.de