On 06/13/2011 05:53 PM, Michal Marek wrote:
Today I finally got round to properly fix the versioning mess in master and the upstream
branches (vanilla and linux-next). This
mail is meant to document how it's supposed to work. You can skip to the table at
the end of the mail for a summary.
Upstream git tags look like "v3.0-rc1", "v3.0-rc2", the final tag is
going to be "v3.0" and the subsequent stable releases will
be tagged as "v3.0.1", "v3.0.2" and so on. The tarballs are named
after these tags, so we have linux-3.0-rc2.tar.bz2 that
contains the linux-3.0-rc2 directory.
HOWEVER: Several userspace programs expect the kernel release string be three numbers and
fail if it isn't the case. This also
affects depmod, so omitting the third zero would break all setups using modules. So the
kernel continues to call itself
"3.0.0-rc2" and this will probably stay for some time now.
In short, there are two version numbers now: I'll refer to them as the
"tarball" version and the "uname" version (might differ
from the "tarball" version in the trailing zero).
The SRCVERSION variable in the config.sh file is set to the "tarball" version.
The mkspec script takes this and generates two
more versions: The "uname" version (appends a zero if necessary), that is used
during the build (so the actual build didn't
require any modifications in the end) and the "rpm" version. I used the fact
that the build was broken anyway as an opportunity
to revamp the way the rpm packages are numbered. The final releases will have three
numbers, i.e. "kernel-desktop-3.0.0-...",
"kernel-desktop-3.0.1-...", etc. However, -rc releases will use the
"rcX" tag instead of the last zero, so the current package
will look like "kernel-desktop-3.0.rc2-...". Letters sort before numbers in
rpm, so this will not break ordering and at the same
time you will be able to tell the upstream version from the rpm version easily. Until
now, we abused the rpm Release: field for
this, but this only worked in the Kernel:* projects and not in the official distribution.
To summarize, the mapping will be like:
rpm tarball uname -r
kernel-desktop-3.0.rc2-* linux-3.0-rc2.tar.bz2 3.0.0-rc2-*-desktop
kernel-desktop-3.0.0-* linux-3.0.tar.bz2 3.0.0-*-desktop
kernel-desktop-3.0.1-* linux-3.0.1.tar.bz2 3.0.1-*-desktop
The "*" above is the rpm Release: number assigned by the build service. I hope
that despite the long mail, the scheme will
actually be easy to understand, that would will be able to quickly tell what kernel is in
the distro by just looking at the rpm
PS: I didn't cover KMPs at all at this point, they might work or there might be some
fixes needed, I'll look into this later.
Hey thanks Michal for the explanation.
I'm just afraid about how much factory tester will forget to upgrade 3.0.rc2 to
3.0.[0-9] as zypper/rpm/solver will always
consider it a downgrade version.
This is seen regularly with obs when people build svn or git version.
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member & Ambassador
GPG KEY : D5C9B751C4653227
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org