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 physik fu-berlin de
Attachment:
pgp00008.pgp
Description: PGP signature