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