> 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?
Existing, or absolute maximum?
$ rpm -qp --qf "%{EPOCH}\n" libarts1-1.1.3-7mdk.i586.rpm
30000001
:-(
But, 30092001 is still bigger than 30091001
> 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.
Yes, this is the idea.
>
> 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.
I had wondered about possibly having an approach closer to what FreeBSD
has, where we have a 9.x branch and a 10.x branch, and after a certain
point, end-users should be happy to test with it, and at some point goes
into maintenance.
It might be better to combind both ideas, but this doesn't have too large
an impact on using the epochs or not (although it may be an advantage of
managing the epochs well).
>
> 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.
I don't think the epoch should be abused like that. Sub-release numbers
(ie 0.alpha24.3mdk) are fine for this.
> How much of this could we do without confusing people too much? How
> complex would it be to set up the corresponding RPM macros?
I don't think rpm macros will be a good solution, since any buildrequires
with epoch values will need to be adjusted, so either we're going to be
doing shell arithmetic in rpm macros for the epoch values, or rpm needs to
be appropriately hacked ...
Regards,
Buchan
