Kind request: Set release version to "10"

Axel Thimm Axel.Thimm at physik.fu-berlin.de
Wed Oct 1 15:00:51 UTC 2003


On Wed, Oct 01, 2003 at 01:56:24PM +0200, Michael Schwendt wrote:
> On Wed, 1 Oct 2003 12:12:47 +0300, Axel Thimm wrote:
> > > With the Epoch: (which went from 0 to 1 on the redhat-release package),
> > > everything works out fine and is rpm-increasing.
> > You have to do it for each package in a multiple concurrent
> > release supporting repo that exists for multiple releases of
> > RH. Read up this thread for details and examples.
> 
> How many packages would that be?

How many? All the ones from my repo for instance. Same for other
repos. Some of the repos have intertwining dependencies that would
also need to be updated.

No, I won't enter that epoch hell, and probably neither will any other
repo maintainer.

> Consider the package naming scheme of fedora.us which uses the
> following target release tags:
> 
>   rh80 < rh90 < rh90.93 < 0.94

That's a kludge (BTW it should have been rh8.0 < rh9 < rh9.0.93). What
about repos not using the rh tag and what about repos not willing to
give up identification of the rpm as belonging to the rh family? What
about Fedora Legacy, should part of it be distro-tagged and some not
(like your example above)?

> No problems during upgrades. The other example (kernel) doesn't hold
> true for Fedora Core, because 0.94 contains a kernel version which is
> higher than Red Hat Linux 9, 8.0 and older releases:
> 
>   2.4.20-20.9 < 2.4.22-1.2061.nptl
>   2.4.20-20.8 < 2.4.22-1.2061.nptl
>   2.4.20-20.7 < 2.4.22-1.2061.nptl

Of course it works when the package version is newer, I am talking of
keeping the same package built for different releases (e.g. built form
the same specfile). Version bumping is the reason, why RH didn't
encounter that problem that often (other than the few common errata).

> Even if there were a kernel upgrade for RHL<=9, I'm sure it would see
> a lower package release version than what is in Fedora Core, e.g.
> 2.4.22-2 in Fedora Core and 2.4.22-1.9 in Shrike Updates.

Rawhide kernel specfile even has special precautions for RH7
(sevenexcompat macro), so the current intention obviously is to
continue the common errata method, if the severn kernel turns out to
be stable enough. I pitty the kernel rpm maintainer for having to come
up with yet-another-custom-made-versioning-scheme.

Even if this should not be the case with the kernel rpm, it was only a
RH-internal example to visualize to RH devels what exists in numbers
of several hunderds in other repos. Any kludgy version numbering trick
for the next common kernel rpm release may work for that one package,
but we need a solution covering the general case.
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031001/632654cc/attachment.sig>


More information about the fedora-devel-list mailing list