Ben appelons un chat, un chat. Si c'est un 2.4.21-pre4, c'est pas un 2.4.21. Pour l'annonce, on peut faire :
- Linux 2.4.21 (prerelease)
- Linux 2.4.21 (release candidat)
et ça roule nickel.
Next in the package label is an identifier that describes the version of the software being packaged. If the package builder bundled a number of related programs together, the software version is probably a number of their own choosing. However, if the package consists of one major application, the software version normally comes directly from the application's developer. The actual version specification is quite flexible, as can be seen in the examples above. The versions shown are: 1.0 and 5.001m. A dash separates the software version from the remainder of the package label."
- "The version is the number from the unpatched sources. It is the version number in the name of the original archive file: name-version.tar.gz."
Pour kernel-2.4.21.0.13mdk-1-1mdk.src.rpm dans le .spec on a un "horrible" :
%if %use_patch
%define tar_version 2.4.%(expr %sublevel - 1)
[...]
%else
%define tar_version 2.4.%sublevel
[...]
%endif
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-%(...){tar_version}.tar.bz2
Mais il y a une explication dans le .spec de kernel-2.4.21.0.13mdk-1-1mdk.src.rpm.
Attention, c'est long et compliqué !
------------------------------------------------------------
# First: Get versions names right is complicated (tm)
# Second: kernel allways have the version & release number in the name
# this is done to preserving a working kernel when you install
# a new one
# Stored in %rpmrversion & %rpmrelease
#
# We want to reflect in the kernel naming:
# - vanilla kernel in with is based (ex. 2.4.21)
# this version is stored in %realversion
# - Number of Mandrake kernel based on this vanilla kernel (ex. 2mdk).
# stored in %mdkrelease.
#
# That gives us a nice name: 2.4.21.2mdk
#
# As version and release are allways fixed, name of the package is
# going to be:
# kernel-2.4.21.2mdk-1-1mdk
#
# Confused already?
#
# Now there arrive pre/rc kernels. This kernels have the particularity
# that they have the name of the new kernel, but they are based in the
# tar file of the old kernel, i.e. names are basically:
# - vanilla kernel: 2.4.21
# - patch name: 2.4.22-pre3
# stored in %use_patch
# - Number of Mandrake kernel based in this pre kernel 2mdk
#
# That gives us a nice name again: 2.4.22.pre3.2mdk
# Problems now are:
# - sublevel of vanilla kernel 21 (needed for tar file)
# - sublevel of kernel is 22 (needed for prepatch and naming
# the package).
# This explains the need of %tar_version, because this will be different
# of %real_version if there is a pre/rc patch.
#
# Still with me?
#
# There are still a problem, when real 2.4.22 cames out, it will have
# a mane like:
# 2.4.22.1mdk
# this name is (for rpm ordering of versions) smaller than:
# 2.4.22.pre3.2mdk
# to fix that we add a 0 to the name (and appear the need of realrelease)
# in the pre/rc
# 2.4.22.0.pre3.2mdk
#
# Take one aspirine. Relax.
#
# Problem now is that names are just really ugly, and specially
# lilo/grub names are very difficult to read/type.
# Notice that the extra .0 is there only to make visual comparations
# easy, but it is an annoyance.
#
# Lilo name for this kernel will be:
# 2422-0.pre3.2mdk
# And as everybody knows, putting dot's in lilo names is not nice.
# Then we change the kernel name (for loaders, and directory names only)
# to a more userfriendly:
# 2.4.22pre3-2mdk
# That way, smp, enterprise versions continue to have the well known names
# in the loader of:
# 2422pre3-2smp
#
# This is the reason of having %kernelrelease.
# As you know, all programers are lazy. And they don't like to have
# the same errors once and more times.
# The following rpm/shell engineering is used to be able to calculate
# all the names exposed previosly from only the following 3 variables.
# If you don't have a pre/rc patch, define %use_patch to 0, otherwise
# define it to the patch name (i.e. pre3 or rc2).
#
# For a non pre/rc kernel define (real examples in brakets)
# 2.4.X.Ymdk [2.4.22.2mdk]
# where
# %sublvel = X [22]
# %mdkrelease = Y [2]
# %use_patch 0 [0]
#
# For a pre/rc kernel do:
# 2.4.X.0.Y.Zmdk [2.4.22.0.pre3.2mdk]
# where
# %sublvel = X [22]
# %mdkrelease = Z [2]
# %use_patch Y [pre3]
#
# I hope this is all clear now. If you have any doubt, please mail me at:
#
# Juan Quintela <quintela@mandrakesoft.com>
------------------------------------------------------------
Es que l'effet d'annonce justifiait ce "truc". RedHat ne se prend pas la tête avec ces "conneries" (noté bien les "" avant de m'allumer). Pour de kernel rawhide (2.4.21pre7) il utilise 2.4.20 car c'est basé sur un 2.4.20 officiel. Pour le kernel de la RH9 (2.4.21pre3) c'est kernel-2.4.20-9. Celui que ça intéresse peut fouiller le src.rpm pour vérifier si c'est un 2.4.n+1-pre? .
[^] # Re: Conectiva Linux 9 est disponible
Posté par matiasf . En réponse à la dépêche Conectiva Linux 9 est disponible. Évalué à 2.
- Linux 2.4.21 (prerelease)
- Linux 2.4.21 (release candidat)
et ça roule nickel.
Enfin, l'autre problème c'est le nom respet de la norme rpm.
http://www.rpm.org/max-rpm/s1-intro-to-rpm-whats-in-package.html(...)
- "Component #2: The Software's Version
Next in the package label is an identifier that describes the version of the software being packaged. If the package builder bundled a number of related programs together, the software version is probably a number of their own choosing. However, if the package consists of one major application, the software version normally comes directly from the application's developer. The actual version specification is quite flexible, as can be seen in the examples above. The versions shown are: 1.0 and 5.001m. A dash separates the software version from the remainder of the package label."
Et Mandrake dit la même chose :
http://www.mandrakelinux.com/howtos/mdk-rpm/building.html#AEN267(...)
- "The version is the number from the unpatched sources. It is the version number in the name of the original archive file: name-version.tar.gz."
Pour kernel-2.4.21.0.13mdk-1-1mdk.src.rpm dans le .spec on a un "horrible" :
%if %use_patch
%define tar_version 2.4.%(expr %sublevel - 1)
[...]
%else
%define tar_version 2.4.%sublevel
[...]
%endif
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-%(...){tar_version}.tar.bz2
Mais il y a une explication dans le .spec de kernel-2.4.21.0.13mdk-1-1mdk.src.rpm.
Attention, c'est long et compliqué !
------------------------------------------------------------
# First: Get versions names right is complicated (tm)
# Second: kernel allways have the version & release number in the name
# this is done to preserving a working kernel when you install
# a new one
# Stored in %rpmrversion & %rpmrelease
#
# We want to reflect in the kernel naming:
# - vanilla kernel in with is based (ex. 2.4.21)
# this version is stored in %realversion
# - Number of Mandrake kernel based on this vanilla kernel (ex. 2mdk).
# stored in %mdkrelease.
#
# That gives us a nice name: 2.4.21.2mdk
#
# As version and release are allways fixed, name of the package is
# going to be:
# kernel-2.4.21.2mdk-1-1mdk
#
# Confused already?
#
# Now there arrive pre/rc kernels. This kernels have the particularity
# that they have the name of the new kernel, but they are based in the
# tar file of the old kernel, i.e. names are basically:
# - vanilla kernel: 2.4.21
# - patch name: 2.4.22-pre3
# stored in %use_patch
# - Number of Mandrake kernel based in this pre kernel 2mdk
#
# That gives us a nice name again: 2.4.22.pre3.2mdk
# Problems now are:
# - sublevel of vanilla kernel 21 (needed for tar file)
# - sublevel of kernel is 22 (needed for prepatch and naming
# the package).
# This explains the need of %tar_version, because this will be different
# of %real_version if there is a pre/rc patch.
#
# Still with me?
#
# There are still a problem, when real 2.4.22 cames out, it will have
# a mane like:
# 2.4.22.1mdk
# this name is (for rpm ordering of versions) smaller than:
# 2.4.22.pre3.2mdk
# to fix that we add a 0 to the name (and appear the need of realrelease)
# in the pre/rc
# 2.4.22.0.pre3.2mdk
#
# Take one aspirine. Relax.
#
# Problem now is that names are just really ugly, and specially
# lilo/grub names are very difficult to read/type.
# Notice that the extra .0 is there only to make visual comparations
# easy, but it is an annoyance.
#
# Lilo name for this kernel will be:
# 2422-0.pre3.2mdk
# And as everybody knows, putting dot's in lilo names is not nice.
# Then we change the kernel name (for loaders, and directory names only)
# to a more userfriendly:
# 2.4.22pre3-2mdk
# That way, smp, enterprise versions continue to have the well known names
# in the loader of:
# 2422pre3-2smp
#
# This is the reason of having %kernelrelease.
# As you know, all programers are lazy. And they don't like to have
# the same errors once and more times.
# The following rpm/shell engineering is used to be able to calculate
# all the names exposed previosly from only the following 3 variables.
# If you don't have a pre/rc patch, define %use_patch to 0, otherwise
# define it to the patch name (i.e. pre3 or rc2).
#
# For a non pre/rc kernel define (real examples in brakets)
# 2.4.X.Ymdk [2.4.22.2mdk]
# where
# %sublvel = X [22]
# %mdkrelease = Y [2]
# %use_patch 0 [0]
#
# For a pre/rc kernel do:
# 2.4.X.0.Y.Zmdk [2.4.22.0.pre3.2mdk]
# where
# %sublvel = X [22]
# %mdkrelease = Z [2]
# %use_patch Y [pre3]
#
# I hope this is all clear now. If you have any doubt, please mail me at:
#
# Juan Quintela <quintela@mandrakesoft.com>
------------------------------------------------------------
Es que l'effet d'annonce justifiait ce "truc". RedHat ne se prend pas la tête avec ces "conneries" (noté bien les "" avant de m'allumer). Pour de kernel rawhide (2.4.21pre7) il utilise 2.4.20 car c'est basé sur un 2.4.20 officiel. Pour le kernel de la RH9 (2.4.21pre3) c'est kernel-2.4.20-9. Celui que ça intéresse peut fouiller le src.rpm pour vérifier si c'est un 2.4.n+1-pre? .