kernel-module rpm's - final decision?

[Troy Dawson]

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
-- 
__________________________________________________
Troy Dawson  dawson(a)fnal.gov  [phone]
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________

[Tom Callaway]

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!

[Tom Callaway]

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!

[Ville Skyttä]

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

[Chuck Anderson]

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

[Ville Skyttä]

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?

[Tom Callaway]

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!

[Troy Dawson]

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.

-- 
__________________________________________________
Troy Dawson  dawson(a)fnal.gov  [phone]
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________