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