On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
> On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
> > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
> > > As an aside, I didn't think Extras was ready to tackle the issue of
> > > kernel module packages yet.
> >
> > Right, at least three issues remain: how to name the modules, how to
> > make depsolvers do the right thing with them, and how to request builds
> > for i586 and i686 from the build system for the same package.
>
> Screw i586 for now. As for naming, the kernel version needs to be stored
> *somewhere*. And we need to finalize the naming issue before we can
> decide what behavior depsolvers need.
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:
- 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:
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")
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).
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.
~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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
