Hi,
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:
[hans@shalem ~]$ rpm -q kernel kernel-3.8.3-203.fc18.x86_64 kernel-3.8.4-202.fc18.x86_64 kernel-3.8.5-201.fc18.x86_64
Notice how as the kernel versions get newer the release gets older ...
Regards,
Hans
On Mon, Apr 1, 2013 at 9:38 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
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.
[hans@shalem ~]$ rpm -q kernel kernel-3.8.3-203.fc18.x86_64 kernel-3.8.4-202.fc18.x86_64 kernel-3.8.5-201.fc18.x86_64
Notice how as the kernel versions get newer the release gets older ...
http://lists.fedoraproject.org/pipermail/kernel/2013-January/004062.html
josh
Hi,
On 04/01/2013 03:40 PM, Josh Boyer wrote:
On Mon, Apr 1, 2013 at 9:38 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
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.
http://lists.fedoraproject.org/pipermail/kernel/2013-January/004062.html
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 ?
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...
Regards,
Hans
On Mon, 2013-04-01 at 15:48 +0200, Hans de Goede wrote:
Hi,
On 04/01/2013 03:40 PM, Josh Boyer wrote:
On Mon, Apr 1, 2013 at 9:38 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
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.
http://lists.fedoraproject.org/pipermail/kernel/2013-January/004062.html
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 observation was: "Notice how as the kernel versions get newer the release gets older ..." This has always been the case with every package. We just have different starting point based on release.
Justin
Hi!
On 01.04.2013 15:40, Josh Boyer wrote:
On Mon, Apr 1, 2013 at 9:38 AM, Hans de Goede hdegoede@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.
[hans@shalem ~]$ rpm -q kernel kernel-3.8.3-203.fc18.x86_64 kernel-3.8.4-202.fc18.x86_64 kernel-3.8.5-201.fc18.x86_64
Notice how as the kernel versions get newer the release gets older ...
http://lists.fedoraproject.org/pipermail/kernel/2013-January/004062.html
Questions like this seem to come up every now and then on different mailing lists, forums and IRC since the change that lead to the current behavior was done a few weeks ago. Even experienced packagers seem to get confused afaics. I don't think that's worth the time spend, so I'm going to propose a different solution, even if I know it was shut down with "no more bikeshedding, we found a solution, move on people" or IRC a few weeks ago:
Why not simply move the disttag right at the start or %release and then use a normal number behind it as release number (that would have lead to this kernel-3.8.3-fc18.3.x86_64 kernel-3.8.4-fc18.2.x86_64 kernel-3.8.5-fc18.1.x86_64 )? That solves the update path problem when people go from Fedora <something> to Fedora <something+(1|2)> and doesn't involve numbers in the hundreds. Or am I missing something?
CU knurd
kernel@lists.fedoraproject.org