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

Re: Fedora and Fedora Legacy package versioning schemes



Thank you for your well written proposal.

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.


(Read the bottom of this message for a summary of my %{release} naming proposal.)

The easiest way to achieve a) and b) is to have

Release: 4_%{disttag}

in the specfile and let %{disttag} expand to values in the right
rpm-order for the given distributions.

A proposal on the fedora.us side is to allow rpm to compare "rh9"
versus "1", which under newer rpms will resolve as older, but which is
not the case for RH7.x (possibly even stock RH8.0, but I may be
mistaken). There are updated rpm rpms fixing this issue, but they are
neither available via RHN, nor can Fedora Legacy assume that those
rpms are available on the system to be upgraded.

Therefore it is far better to compare numbers only with rpm.

So we need a versioning scheme f that numerically sorts

... < f("7.3") < f("8.0") < f("9") < f("1") < ...

Possible solutions:
===================

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.

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


-999
We should always maintain upgradability between distributions, and Fedora will strengthen this and prevent problems by stricter packaging standards than those enforced by RH internally in the past. There is currently absolutely no reason to break upgradability.


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.



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.

  It would be good to have a scheme applicable to both Fedora Legacy
  as well as Fedora (current release). That way Fedora releases could
  automatically become Fedora Legacy without rebuilding and
  re-versioning.


+1


o Use the same versioning for RawHide/Betas.

  This would help building more often for RawHide. E.g. the following
  scheme could be used until now:

	 foo-1.2.3-4_rh8.0
	 foo-1.2.3-4_rh8.0.93 (beta)
	 foo-1.2.3-4_rh8.0.94.20030325 (rawhide)
	 foo-1.2.3-4_rh9 (release)


+1
I dislike your specific examples that contain "rh", but the numbers I fully agree.


Warren's Release Naming Proposal (draft 1)
==========================================
All distributions in Fedora Legacy must upgrade to the latest version of rpm for that distribution.


%{release} name structure
-------------------------
X.%{non-numeric version}.%{distrel}

X
RPM package release number, always increments with every update, even a rebuild.
%{non-numeric version}
Non-numeric characters at the end of upstream's %{version}. Since %{version} must (almost) never contain non-numeric characters in order to avoid the Epoch treadmill (like mozilla package), the non-numeric portion can optionally be contained within the %{release} tag after the release number.
Examples:
mozilla-1.5-5.rc2
foobar-2.0-7.cvs20031005


%{distrel} Upgrade Path from fedora.us
--------------------------------------
0.fdr.X.rh80 -> 0.fdr.X.rh90 -> 0.fdr.X.0.94 -> 0.94 -> 1

fedora.us currently has an even longer "0.fdr.X" prepended before the suggested fedora.redhat.com scheme. Thus absolutely anything containing numbers in the second glob will "win" against "fdr".

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?

Warren




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