-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote:
> > > A few observations: In your repository I don't see
a consistent
> > > platform specific release tag scheme.
> >
> > check the dates and the discussion on fedora.us in March/April (yes, I
> > was once a fedora member).
>
> Been there before I joined the fedora-devel(a)fedora.us list. Going
> through list archives is a time-consuming process. I prefer
> summaries of ready-to-use concepts which can be commented on as a
> whole.
> You don't answer why some of your packages have no distribution specific
> release tag at all and why other packages override versions found in Red
> Hat Linux.
What I wanted to say is that the versioning scheme evolved, partly on
its own, partly in discussion within (the old) fedora. So when you
find inconsistency in the repo you are seeing at different layers of
history.
I fail to see that. Here's one of the packages for Shrike, which
was touched long after the disttag discussions:
mplayer-0.90-18.athlon.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/mplayer/mplayer-0.90-18.athlon...
Or this one from July (0.9 = Shrike?):
perl-DateManip-5.42-0.9.noarch.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/perl-DateManip/perl-DateManip-...
Another one for Shrike, from the same period of time, but has a disttag:
libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/apt/libapt-pkg-devel-0.5.5cnc6...
So much about consistency. There are more examples like that.
Back to the topic.
> Continueing Fedora Core with Red Hat Linux specific release
numbers
> does not sound reasonable. It is like an implicit epoch.
OTOH you are right, but if the packages from the Fedora Project are to
be related to Red Hat Linux ones (e.g. you want them to be rpm-newer),
you need to come up with a compatible scheme.
Packages in Fedora Core 1 will be newer than any packages in Red Hat
Linux. Only a few cases (e.g. comps, maybe comps-extras,
redhat-release => fedora-release) need special treatment (probably an
increased epoch).
I understand that Red Hat have never supported an upgrade path from
installations other than Red Hat Linux. The Fedora Project is a new
thing. It doubt it changes history by treating old 3rd party
repositories for Red Hat Linux as if they had been official Fedora
Extras/Alternatives/Legacy repositories before. In other words, they
are unsupported. Starting with Fedora Core 1 you may need to implement
a compatible versioning scheme, i.e. bump the release versions or
vepochs (if any) of all your old packages before you put them into
your Fedora add-ons repository. As I've pointed out before, some of
your package versions conflict with Red Hat Linux anyway (e.g. bash,
perl-DateManip, mozilla).
Did you check Warren's proposal on doing the reverse? E.g.
instead of
continuing RHL versioning into Fedora, one can back-continue Fedora
guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0.
Yes, sounds good. It's not the first time a "0." prefix is useful.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gchv0iMVcrivHFQRAslfAJ9Ot/0Jrg+idu3H9V6aAgfDaglXmgCeOTC1
Ar1JDanpiVcP03zzeURtaVc=
=TlhL
-----END PGP SIGNATURE-----