On Fri, 7 Nov 2003 01:09, Buchan Milne wrote: >> This would need >> some rpm changes, so that a package built on 9.2 would have an >> epoch of 92 and one build on 10.0 would have epoch 100. But this >> would be a problem with packages that already has an epoch, as you >> can use only integer numbers for the epoch tag.
> It could also cause some problems for Requires/BuildRequires with > epoch values? Any BuildRequires/Requires with an existing Epoch value > would need to be bumped also, which makes for some additional > 'macro-isation' for the packager, and makes it difficult to automate > this. How big can the epoch be? If you used release * 100 + existing, would that work? So if a package was up to epoch 42, you would get 9242 for the current release and 10042 for the same package aimed at 10.0. Next question, how about switching to even release numbers for stable releases and odd for Cooker? That would make the epoch 9342 for the pre-10.0 Cooker, 10042 for the 10.0 release, 10142 for the post-10.0 Cooker, 10242 for the next release (10.2, there is no 10.1), presuming that no version bumps happened in between times. This would violate tradition in that the releases would go 9.2, 10.0, 10.2, 10.4, 11.0,... but it would be understandable to anyone used to the kernel versioning system and ordinary end-users shouldn't notice much or care much either. If we have room for one more digit, we could use that for the alpha, beta and RC releases; so 93042 is the Cooker version of the package, 93142 is the alpha, betas run from 93242 to as high as 93542 then RCs from 93642 up to (heaven forbid) a potential 93942, then 100042 for the 10.0 final. How much of this could we do without confusing people too much? How complex would it be to set up the corresponding RPM macros? Cheers; Leon
