3:59 p.m.
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
for the next kernel version to do it, just the next gitN.
We can't make this change until 2.6.23 sails, since for rpm version
comparison rc* is < any [0-9].
--- kernel.spec 09 Aug 2007 13:45:09 -0700 1.72
+++ kernel.spec 09 Aug 2007 13:46:42 -0700
@@ -126,7 +126,7 @@ Summary: The Linux kernel (the core of t
%define rctag .rc0
%endif
%endif
-%define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist}
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}%{?dist}
%endif
# The kernel tarball/base version
4:03 p.m.
On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
for the next kernel version to do it, just the next gitN.
We can't make this change until 2.6.23 sails, since for rpm version
comparison rc* is < any [0-9].
Please don't do this. The kernel package is finally compliant with the
Fedora Packaging Guidelines and this change would break it again.
The reason we prefix with the 0.# is to prevent versioning comparison
madness.
If you need to do a fast rebuild, append a .# after the %{?dist}.
~spot
4:21 p.m.
On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
> I propose we change the release format for snapshot kernels.
> Now we get e.g.:
>
> kernel-2.6.23-0.89.rc2.git2.fc8
>
> and I suggest instead:
>
> kernel-2.6.23-0.rc2.git2.89.fc8
>
> That is, put the spec file version number last, not first. This way, when
> we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
> for the next kernel version to do it, just the next gitN.
>
> We can't make this change until 2.6.23 sails, since for rpm version
> comparison rc* is < any [0-9].
Please don't do this. The kernel package is finally compliant with the
Fedora Packaging Guidelines and this change would break it again.
The reason we prefix with the 0.# is to prevent versioning comparison
madness.
What? I didn't propose removing the 0. prefix. What is the problem?
7:07 p.m.
On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote:
>
> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
> > I propose we change the release format for snapshot kernels.
> > Now we get e.g.:
> >
> > kernel-2.6.23-0.89.rc2.git2.fc8
> >
> > and I suggest instead:
> >
> > kernel-2.6.23-0.rc2.git2.89.fc8
> >
> > That is, put the spec file version number last, not first. This way, when
> > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
> > for the next kernel version to do it, just the next gitN.
> >
> > We can't make this change until 2.6.23 sails, since for rpm version
> > comparison rc* is < any [0-9].
>
> Please don't do this. The kernel package is finally compliant with the
> Fedora Packaging Guidelines and this change would break it again.
>
> The reason we prefix with the 0.# is to prevent versioning comparison
> madness.
What? I didn't propose removing the 0. prefix. What is the problem?
Look closer, there's a `#´ in Tom's reply, which is what you want to
move away. Actually the 0. prefix is not neccessary it is a leftover
from 3rd party techniques to indicate vendor hierarchies, but it's
difficult to knock out people's head.
The important bit is that by having the `#´ before the part-of-the-
version-that-had-to-be-banned-to-the-release-tag-because-otherwise-the-
version-would-not-properly-increment you become independent of any
upstream versioning trickery. git/rc versioning is not that new, and who
knows whether next year we'll have pre/rc/gold/ga/pl madness in
upstream sub-versioning.
So please keep the buildtag as `#´ is often referred to before the
part-of-the-version-that-had-to-be-banned
--
Axel.Thimm at ATrpms.net
10:22 p.m.
Axel Thimm wrote:
On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote:
>> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
>>> I propose we change the release format for snapshot kernels.
>>> Now we get e.g.:
>>>
>>> kernel-2.6.23-0.89.rc2.git2.fc8
>>>
>>> and I suggest instead:
>>>
>>> kernel-2.6.23-0.rc2.git2.89.fc8
>>>
>>> That is, put the spec file version number last, not first. This way, when
>>> we forget to reset fedora_cvs_origin after a rebase, we don't have to
wait
>>> for the next kernel version to do it, just the next gitN.
>>>
>>> We can't make this change until 2.6.23 sails, since for rpm version
>>> comparison rc* is < any [0-9].
>> Please don't do this. The kernel package is finally compliant with the
>> Fedora Packaging Guidelines and this change would break it again.
>>
>> The reason we prefix with the 0.# is to prevent versioning comparison
>> madness.
> What? I didn't propose removing the 0. prefix. What is the problem?
Look closer, there's a `#´ in Tom's reply, which is what you want to
move away. Actually the 0. prefix is not neccessary it is a leftover
from 3rd party techniques to indicate vendor hierarchies, but it's
difficult to knock out people's head.
It has nothing to do with any 3rd-party techniques in the case. The
'0.#' instead of just '#' is so that we can rebase the release number to
1 on each new major kernel version, so the first released 2.6.23 kernel
for fc8 will be 2.6.23-1.fc8. At least, that was my intention when I
wrote this stuff up, and its how we've used it thus far.
Of course, my initial thought had been it'd be nice to not even have the
'.#' portion in there, since you get reasonably decent rpm ordering with
just 0.rcX.gitY.fc8, but then if we end up doing a rebuild of the same
git snap, you have to worry about it, but we don't want to have to muck
around with that manually. That being the case, putting it after the
leading 0 for git snaps, automatically incremented over the period
leading up to the next kernel release, in line with the packaging
guidelines, made the most sense.
--
Jarod Wilson
jwilson(a)redhat.com
1:50 a.m.
On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote:
>Actually the 0. prefix is not neccessary it is a leftover from
3rd
>party techniques to indicate vendor hierarchies, but it's difficult
>to knock out people's head.
It has nothing to do with any 3rd-party techniques in the case. The
'0.#' instead of just '#' is so that we can rebase the release number to
1 on each new major kernel version,
It has everything to do with 3rd parties and the key element here is
history: Many years ago we started to discuss the beginning of what
today became the packaging guidelines in fedora.us. One element was
what to do with packages that override the vendors' (RHL 6.x/7.x at
that time), especially when the vendor was shippijng foo-1 and one
would like to use foo-3.
So foo-3-0.whatever was considered as a hierachy solution to allow the
vendor to catch up with the 3rd party package w/o the vendor having to
coordinate build tags with the little 3rd party repos.
In reality many foo-1 -> foo-3 upgrades were for foo-3 = some
prerelease, so this idiom got confused for prepending a 0. to
prereleases.
So, "0." had a semantic wandering to land where it's used now, and the
beginnings were 3rd party techniques to auto-overide their own
packages when the vendor would update his.
</history_lesson> ;)
There is nothing wrong with not using "0." to mark prereleases, it's
just Fedora legacy/tradition. I'm not a fan of resetting the build tag
anyway.
But whatever the "0." the important thing is that the build tag (`#´)
remains in front even if today the sub-versioning scheme for the
kernel looks like it would automatically happen to fit in rpmvercmp
ordering. Another history lesson shows that once one thought a
versioning style would settle and work it is "usefully" extended in a
way as to break theis assumption ;)
--
Axel.Thimm at ATrpms.net
9:06 a.m.
Axel Thimm wrote:
On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote:
>> Actually the 0. prefix is not neccessary it is a leftover from 3rd
>> party techniques to indicate vendor hierarchies, but it's difficult
>> to knock out people's head.
> It has nothing to do with any 3rd-party techniques in the case. The
> '0.#' instead of just '#' is so that we can rebase the release number
to
> 1 on each new major kernel version,
It has everything to do with 3rd parties and the key element here is
history: Many years ago we started to discuss the beginning of what
today became the packaging guidelines in fedora.us. One element was
what to do with packages that override the vendors' (RHL 6.x/7.x at
that time), especially when the vendor was shippijng foo-1 and one
would like to use foo-3.
So foo-3-0.whatever was considered as a hierachy solution to allow the
vendor to catch up with the 3rd party package w/o the vendor having to
coordinate build tags with the little 3rd party repos.
In reality many foo-1 -> foo-3 upgrades were for foo-3 = some
prerelease, so this idiom got confused for prepending a 0. to
prereleases.
So, "0." had a semantic wandering to land where it's used now, and the
beginnings were 3rd party techniques to auto-overide their own
packages when the vendor would update his.
</history_lesson> ;)
Yes, there's history behind why the "0." convention is in the packaging
guidelines, but I still maintain that the 3rd-party history has/had zero
bearing on the decision to use it in the kernel package.
There is nothing wrong with not using "0." to mark
prereleases, it's
just Fedora legacy/tradition. I'm not a fan of resetting the build tag
anyway.
I think your distaste of resetting the build tag is the real sticking
point here. The main reason for "0.<buildtag>" in pre-release versioning
is because the majority of people *are* fans of resetting the build tag.
But whatever the "0." the important thing is that the build
tag (`#´)
remains in front even if today the sub-versioning scheme for the
kernel looks like it would automatically happen to fit in rpmvercmp
ordering. Another history lesson shows that once one thought a
versioning style would settle and work it is "usefully" extended in a
way as to break theis assumption ;)
True, true... rh9 -> fc1, fc6 -> f7... :)
--
Jarod Wilson
jwilson(a)redhat.com
4:11 p.m.
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
for the next kernel version to do it, just the next gitN.
Is it that big a deal? I intended to only reset the origin after each
point release, so it doesn't really buy us anything being able to change
this with every -git.
Dave
--
http://www.codemonkey.org.uk
4:24 p.m.
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote:
> I propose we change the release format for snapshot kernels.
> Now we get e.g.:
>
> kernel-2.6.23-0.89.rc2.git2.fc8
>
> and I suggest instead:
>
> kernel-2.6.23-0.rc2.git2.89.fc8
>
> That is, put the spec file version number last, not first. This way, when
> we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
> for the next kernel version to do it, just the next gitN.
Is it that big a deal? I intended to only reset the origin after each
point release, so it doesn't really buy us anything being able to change
this with every -git.
It's not a big deal, it's only numbers. The motivation was that it didn't
get reset when we went from 2.6.22 to 2.6.23, and after one build hits
rawhide, it's too late. Also, it's just better because it accurately
reflects the topology of change. A spec release is a variant of a kernel
snapshot, not vice versa.
4:54 p.m.
On Thu, Aug 09, 2007 at 02:24:44PM -0700, Roland McGrath wrote:
> On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote:
> > I propose we change the release format for snapshot kernels.
> > Now we get e.g.:
> >
> > kernel-2.6.23-0.89.rc2.git2.fc8
> >
> > and I suggest instead:
> >
> > kernel-2.6.23-0.rc2.git2.89.fc8
> >
> > That is, put the spec file version number last, not first. This way, when
> > we forget to reset fedora_cvs_origin after a rebase, we don't have to
wait
> > for the next kernel version to do it, just the next gitN.
>
> Is it that big a deal? I intended to only reset the origin after each
> point release, so it doesn't really buy us anything being able to change
> this with every -git.
It's not a big deal, it's only numbers. The motivation was that it didn't
get reset when we went from 2.6.22 to 2.6.23, and after one build hits
rawhide, it's too late.
For rawhide, I don't think it really matters too much.
Dave
--
http://www.codemonkey.org.uk
6 a.m.
Le jeudi 09 août 2007 à 14:24 -0700, Roland McGrath a écrit :
Also, it's just better because it accurately
reflects the topology of change. A spec release is a variant of a kernel
snapshot, not vice versa.
Good version ordering is more important than topology
Snapshot names are not always ordered, Fedora shiped non-Linus kernels
in the past (-ac...), etc
--
Nicolas Mailhot
6100
days inactive
6103
days old
kernel@lists.fedoraproject.org
10 comments
6 participants
participants (6)
-
Axel Thimm -
Dave Jones -
Jarod Wilson -
Nicolas Mailhot -
Roland McGrath -
Tom Callaway