Actually, no. I'm not going to standardize kernel module
packaging
_UNTIL_ at least yum is fixed.
Let me reiterate some points that I have made in the past:
Good, gets us all back on track. :-)
- I do not plan to overload the %{name} value for kernel module
packages. This means that we will NOT be shoving the kernel version in
%{name}. Its ugly, it screws up bugzilla, breaks existing packaging
guidelines, and is altogether wrong.
- Given that, we WILL need to put the kernel version (in some part) in
either %{version} or %{release}. Let me explain why:
I can tolerate %{release}
On SMP systems, at a bare minimum, there will be two kernels
installed:
kernel-smp-2.6.12-1.1400_FC5
kernel-2.6.12-1.1400_FC5
If we do not use kernel version in either %{version} or %{release},
we'll have no way to generate two packages with unique
%{name}-%{version}-%{release} values.
We have to assume that each installed kernel will want to have a
matching module addon installed for it.
I originally proposed (back in March) that we put the kernel version in
Release. This is a slightly revised proposal.
Name: kernel-module-openafs
(where the value in the Name field is the name of the module, prepended
with "kernel-module-")
Version: 1.1
(where the value in the Version field is equivalent to the kernel module
version, NOT the kernel version we're building against (in this example,
"1", followed by the build revision, in this example ".1")
So %{version} ends up having the upstream version number and the release
number combined. I think this is the worst part as its confusing to the
packager. Why I advocate requiring %{kver}. However, I did not propose
a solution for a unique NVR for eatch kernel type (smp, xen, etc).
Release: %{kver}
(Where %{kver} is the kernel we're building against)
Requires: kernel-%{_target_cpu} = %{kver}
BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
%{kver} gets passed by the buildsystem, for each kernel found in the
branch for which that package is being built. So, for our example
kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp,
respectively. FC4 and newer kernels have this value in the provides for
"kernel-%{arch}", so it should not be too difficult for the build system
to figure out the correct value for %{kver} from the target kernel
package.
There is no need to use dist tags here, since %{kver} includes the dist
name.
If a bugfix needs to be made to the package, then the .1 (build
revision) is incremented. If a new version of the kernel driver is
released, then the first part of the Version is incremented, and the
build revision is reset to .1 (if it is not .1).
So, after the buildsystem does its thing, we've generated two new binary
rpms:
kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm
kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm
Since no previous packages with those n-v-r's exist, yum installs them,
just as it would kernels, doing the equivalent of an rpm -i action.
Now, on the system we have all four packages installed:
kernel-2.6.12-1.1400_FC5
kernel-module-openafs-1.1-2.6.12-1.1400_FC5
kernel-smp-2.6.12-1.1400_FC5
kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp
But wait, I've found a bug in kernel-module-openafs. Easy enough to fix,
I patch it away, increment my build revision to .2, and we now have
these new packages available:
kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm
kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm
But, here yum doesn't know what to do. We can't do a -i, those packages
would conflict with the existing kernel-module-openafs packages. We
can't do a -U, because then we'd only end up with one
kernel-module-openafs package on the system. What we need yum to do is a
special operation that does the following (only for kernel-module
packages):
- Does any kernel-module-openafs package exist on the system with the
same %{release}?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).
I have a patch for yum that does exactly this except it keys off of the
kernel requires. (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5
require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?)
So in a day or two I could probably have it edited to do the above.
After this process, the system has:
kernel-2.6.12-1.1400_FC5
kernel-module-openafs-1.2-2.6.12-1.1400_FC5
kernel-smp-2.6.12-1.1400_FC5
kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp
Now, if someone is willing and able to write the exception case needed
for yum in kernel-module-* packages, then I think we can document the
remaining standard bits, duct tape the necessary logic into the
buildsystem, and start doing kernel-module-* packages for FC4 and devel.
Since I already have a good bit of the code done...
Spot, the only change I would like in this is to have the build number
not in %{version} but as part of %{release}. So using your example,
kernel-module-openafs-1-2.2.6.12-1.1400_FC5
Where the %{release} == build#.%{kver}
This doesn't add or subtract any complexity from the code in Yum. It
does make the versioning a little easier to grok.
Reading the new mail I got as I wrote this it looks like Matthew and I
agree. Cool.
Jack
~spot
--
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader:
http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <slack(a)quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89