[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora and Fedora Legacy package versioning schemes



On Mon, Oct 06, 2003 at 01:06:30AM -1000, Warren Togami wrote:
> Axel Thimm wrote:
> >Defining the problem domain for Fedora Legacy:
> >==============================================
> >
> >a) We need a versioning scheme that ensures upgradability without
> >   obfuscating too much the VR scheme.
> >b) It should be possible to use the same sources/patches/specfiles with
> >   macro controlled differences
> >c) It should work with older rpm versions, e.g. don't let rpm compare
> >   numbers with letters.
> >
> 
> a + b are perfectly valid, but I see no reason to continue to support 
> the ugly behavior of c, and here's why:
> 
> 1) jbj has long indicated that he wishes all distributions to use the 
> same upgraded version of rpm in order to simplify maintenance.
> 2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they 
> wish to continue to use the repository.  This means that we will be able 
> to avoid a lot of unpredictable behavior (#1) in older versions of rpm, 
> making Legacy distributions easier to support in the long term.
> 3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default 
> rpm is too broken to use.

I partly agree, but imagine the first time initiation of a existing
RH7.3 cluster of machines. The admin would have to manually update the
rpm rpms and then point his up2date/yum/apt config to a "Fedora
Legacy" repo.

Red Hat has been very conservative to replace the rpms in RH8.0 (and
RH7.3) and even when a QA rpm release is pushed into RHN, "Fedora
Legacy" should work with non-updated systems, too (just like you have
to build apt/yum/up2date against a non-updated system).

> >a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10"
> >   or "RawHide 9.1". It looks compatible with RH's policy and would
> >   allow for tags like "rh10" to complete the above scheme.
> 
> -1
> Too confusing to have different numbers and names in different places.

Yes, but even Windows users could cope with different maket and
technical versions, and technically it is the cleanest solution.

> >b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.
> -999

I agree, but this is still a possible solution ;)

> >c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
> >   "number" idiom.
> -1
> 
> >
> >d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora
> >   Project")
> -500
> The whole reason why we had those dist tags was because fedora.us (or 
> freshrpms, or dag, or axel, etc.) were not official repositories.  Now 
> Fedora is official, so I believe we can drop this ugliness that makes 
> the package filename unnecessarily longer.

You are talking about the .fdr. tag, e.g. the repo tag. Drop that by
all means. I am referring to the disttag like rh9 etc.

> > X) Your suggestion here.
> >
> >It is important to have Red Hat's consent on any sollution, as well as
> >a common versioning scheme across repositories of different
> >maintainers to allow for properly formulating cross-repository
> >dependencies and having easy identification by end users.
> >
> >Optional good-to-have semantics:
> >================================
> >o Use the same versioning for Fedora.
> > [...]
> +1
> >o Use the same versioning for RawHide/Betas.
> > [...]
> +1
> I dislike your specific examples that contain "rh", but the numbers I 
> fully agree.

Note that redhat/fedora packages are also distributed on larger
mirrors containing Mandrake, suse etc. rpm. A lot of people get the
wrong rpm. An identification string there is nice-to-have (but nothing
more, the true problem lies not here and this should not distract).

> Examples:
> foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta)
> foobar-1.5-6.rc3_1     (Fedora Core 1)
> foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94)
> foobar-1.5-6.rc3_0.8   (RHL 8.0 Psyche)
> foobar-1.5-6.rc3_0.7.3 (RHL 7.3)
> 
> Note that I used "_" instead of "." in this particular example.  Either 
> of them would work.  The former would be a clearer seperator between the 
> %{distrel} and the rest of the tag, while the latter is slightly easier 
> to type.  I personally don't care which one is used.  Opinions?

I am already using _ for that purpose, and will even ask Jeff in the
future to give _ a higher seperating pririty than .  (but that's
another issue, don't want to get off-topic).

I see another suggestion in your examples (which I didn't clearly read
through the description):

e) Prepend "0." to previous RH releases, e.g.

   0.7.3 < 0.8.0 < 0.9 < 0.9.0.93 < ... < 1.0

I personally like that. so how about conaming "RHL X" to "Fedora Core
0.X" resulting to tags like foo-1.2.3-4_fdr0.7.3 (non-numeric upstream
versions, kernel modules and other special cases aside)?
-- 
Axel Thimm physik fu-berlin de

Attachment: pgp00040.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]