Hello, As we are currently working on our openafs package, I want to make sure our kernel modules for it conform to what was agreed upon. But other than the naming, I didn't see a definate 'this is how to do them' list. (If I missed that, point me to it)
Here's what I saw. My example will be openafs, but I am meaning this for others as well.
Name: kernel-module-openafs Version: 1.3.9 Release: 2.6.9-5.0.3.EL.4 Requires: kernel = 2.6.9-5.0.3.EL Provides: kernel-module-openafs
Then the discussion shifted to whether yum and apt would be able to handle this. And there seemed to be a rumble of "it can be done, but it won't be pretty"
Am I missing a thread? Is this really the way we are planning on doing kernel-modules?
Thanks Troy Dawson
On Wed, 2005-03-02 at 10:51 -0600, Troy Dawson wrote:
Hello, As we are currently working on our openafs package, I want to make sure our kernel modules for it conform to what was agreed upon. But other than the naming, I didn't see a definate 'this is how to do them' list. (If I missed that, point me to it)
Here's what I saw. My example will be openafs, but I am meaning this for others as well.
Name: kernel-module-openafs Version: 1.3.9 Release: 2.6.9-5.0.3.EL.4 Requires: kernel = 2.6.9-5.0.3.EL Provides: kernel-module-openafs
To be fair, we haven't finished the kernel-module-* naming and packaging guidelines. I've been busy. :/
I really think in order for kernel-module packages to be manageable (without disgusting yum and apt hacks), rpm needs to be able to do an "UpdateOnlyOne" operation. Right now, it can't do that, it can only "UpdateOneAndRemoveAllMatches".
However, in the interim, I think the following guidelines should be good practice:
Name: kernel-module-openafs (where the value in the Name field is the name of the module, prepended with "kernel-module-") Version: 1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against) Release: %{kver}.1 (Where %{kver} is the kernel we're building against, and the .1 is a build revision, incremented if we need to make changes to the same version and kernel build) Requires: %{kver}
(Do we need the additional "Provides: kernel-module-openafs", isn't that a given, since the Name: is the same?)
%{kver} isn't a predefined macro, it should be passed at build time by the buildsystem (since there could presumably be multiple kernels in the build environment).
Thoughts?
~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!
On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote:
Requires: %{kver}
Should be:
Requires: kernel = %{kver}
(This doesn't deal well with the SMP case (or arch specifics), I'm open to suggestions here. Maybe we should let RPM pick these deps up for itself?)
~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!
On Wed, 2005-03-02 at 14:00 -0600, Tom 'spot' Callaway wrote:
On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote:
Requires: %{kver}
Should be:
Requires: kernel = %{kver}
(This doesn't deal well with the SMP case (or arch specifics),
That won't really work, not even for the UP kernel, because it's not arch-qualified, and all variants (smp, xen*) have "Provides: kernel = $version" and would thus satisfy the dependency for a UP kernel module package.
More verbose explanation and some suggestions: https://bugzilla.redhat.com/beta/show_bug.cgi?id=149249
On Wed, Mar 02, 2005 at 10:12:37PM +0200, Ville Skyttä wrote:
On Wed, 2005-03-02 at 14:00 -0600, Tom 'spot' Callaway wrote:
On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote:
Requires: %{kver}
Should be:
Requires: kernel = %{kver}
(This doesn't deal well with the SMP case (or arch specifics),
That won't really work, not even for the UP kernel, because it's not arch-qualified, and all variants (smp, xen*) have "Provides: kernel = $version" and would thus satisfy the dependency for a UP kernel module package.
Wasn't there recent discussion about this? I thought the conclusion was that rawhide kernels Provides: kernel-%{arch} = %{version}-%{release} ?
Ah, yes, here it is:
On Mon, 21 Feb 2005 23:51:45 -0500, seth vidal wrote:
A couple of items to mention:
new kernels in fc4 should have:
Provides: kernel-%{arch} = ver-rel
in them now.
so kernel-modules should definitely dep on: kernel-%{arch} so we don't get any arch mixups b/t kernels and kernel-modules.
-sv
However, I don't see this in rawhide kernels yet:
rpm -qp --provides kernel-2.6.10-1.1162_FC4.i686.rpm kernel = 2.6.10 kernel-drm = 4.3.0 kernel = 2.6.10-1.1162_FC4
rpm -qp --provides kernel-smp-2.6.10-1.1162_FC4.i686.rpm kernel = 2.6.10 kernel-drm = 4.3.0 kernel-smp = 2.6.10-1.1162_FC4
On Wed, 2005-03-02 at 22:18 +0200, Ville Skyttä wrote:
On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote:
(Do we need the additional "Provides: kernel-module-openafs", isn't that a given, since the Name: is the same?)
Right, not needed.
I see there's no "Provides: kernel-modules" or somesuch, was that left out on purpose?
If I'm not mistaken, that was used previously to flag the package as something that yum/apt/whatever needed to perform nasty hacks on.
If thats all it serves, then lets not use it. I want to fix it in rpm so we don't need it.
~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!
Ville Skyttä wrote:
On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote:
(Do we need the additional "Provides: kernel-module-openafs", isn't that a given, since the Name: is the same?)
Right, not needed.
I see there's no "Provides: kernel-modules" or somesuch, was that left out on purpose?
Sorry about that. You are correct. When I was writting that I not only had up the e-mails from this list, but also a spec file from our older openafs kernel-module. I basically cut and pasted one too many.
Troy p.s. Sorry for the delay, I wrote that e-mail and then got tied up in a bunch of other stuff.
packaging@lists.fedoraproject.org