On Tue, Oct 07, 2003 at 01:13:49AM +0200, Michael Schwendt wrote:
Rest assured, I'm out of this thread. I'm back when there are
serious
attempts at developing a versioning scheme for Fedora Legacy, such as
using %{release}.0.X.Y (where 0.X.Y is e.g. 0.7.3 for Valhalla and 0.9
for Shrike), instead of trying to find a compromise for current 3rd
party repositories.
You possibly haven't read the thread ...
My final comments here. You're complicating matters. I'm
aware that
for older versions of RPM (<= 4.1 or 4.1.1, I don't know),
rh73 < 1fdr *and* 1fdr < rh73
so that would be a problem for upgrade chanells which don't update RPM
to a better version. But where has been defined that Fedora Legacy
will carry packages with rh* disttags?
Where has anything concerning Fedora Legacy been defined? Isn't that
what this list members are supposed to develop?
Fedora Legacy has other problems that must be considered. Obviously,
packages for a Fedora Legacy supported distribution must have a
higher version than all previous packages (E:V-R based version
comparison) for that distribution *and* all packages of older
distributions. At the same time, Fedora Legacy update packages for
one distribution may not have a higher version than stock packages
of newer distributions, so the upgrade path is not disturbed.
You are describing the same problem.
You can only avoid that with backported fixes, which keep the V in
E:V-R below what is shipped with later distributions, or if you
break upgradability. Whether or not that may be necessary also
depends on the feasibility of backporting security fixes in time.
Not true, that's exactly when an rpm-sortable disttag in the release
tag would help. Check the rest of the thread.
--
Axel.Thimm(a)physik.fu-berlin.de