On Mon, 2013-04-01 at 15:48 +0200, Hans de Goede wrote:
On 04/01/2013 03:40 PM, Josh Boyer wrote:
> On Mon, Apr 1, 2013 at 9:38 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
>> Something is wrong with how the release number for the F-18 kernel
>> package is getting bumped, luckily the actual version is being
>> increased most of the time too, not making it matter much, but
>> still this is clearly wrong:
> There's nothing wrong with it. It's done on purpose. It isn't luck at
> play here. The Version is higher, so the release gets reset.
Ah, I see, but not to the usual value of 1 for release resets.
And I see there the rational for this is upgrade paths, so F-19 will
get a base release of 301, etc until we get a base release of 1001 ?
No, this doesn't go on forever. F19 will be 300 series, on the first
rebase after F17 is EOL they shift and F18 becomes 100, F19 becomes 200.
I understand the logic, but this does not look pretty, and more over
is confusing for people who are somewhat familiar with packaging, since
all other Fedora packages do always reset the release field to 1 on
a version change...
On the one hand it isn't as pretty because all releases don't reset to 1
on a version change, but it solves the problem, and has been working
well for a few months now. In the end, it achieves the desired result
and it's easy to maintain. It really isn't all that confusing within a
given release, the numbers are sequential and reset to a predetermined
value on rebase. I think it was more confusing in your initial query
because you did not take into consideration the rebase. Your original
"Notice how as the kernel versions get newer the release gets
This has always been the case with every package. We just have
different starting point based on release.