SCIENTIFIC-LINUX-DEVEL Archives

December 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Akemi Yagi <[log in to unmask]>
Reply To:
Akemi Yagi <[log in to unmask]>
Date:
Wed, 22 Dec 2010 12:10:27 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
On Wed, Dec 22, 2010 at 10:34 AM, Stephan Wiesand
<[log in to unmask]> wrote:

>>> 5) It builds KABI-dependent kmod-openafs packages.
>>> While the ability to build our traditional kernel-module-`uname -r` packages is still there (and required on SL5, I think, because KABI tracking kmods make little sense there for openafs), this is probably the way to go for packaging the kernel module on SL6 and beyond.
> [...]
>>> When implementing those kmods, I started out from what the elrepo folks are doing, but made a few significant changes. Any comments are very welcome:
>>> o there's a single spec for the userland/kernel-module/kmod packages
>>> o a -debuginfo package is built (taking care the name makes sense)
>>> o weak-modules is called with the --no-initramfs switch
>>> o an abbreviated form of the kernel release is appended to the kmod-openafs package release
>>> The last change was made because I just couldn't stand it that the SRPM could be rebuilt against a different kernel (possibly with an incompatible ABI), resulting in packages with exactly the same n-v-r but very different content. And to avoid the need to touch the spec every time modules for a new kernel are rolled out. So what happens is that the release part of the target kernel's `uname -r`, without the gratuitous architecture and the dist tag, is appended to the kmod's release. This allows for clean updates when the module is built for a later kernel, and to install the right debuginfo package if you have to. But it's different from elrepo.
> [...]
>> This is possibly the greatest part of this source rpm.  Thank you for making an rpm that is able to do both the old and new way.  I know it's a lot of work.
>
> Glad you like it.
>
> Since I have very limited experience with these kmods, it would be really great to hear from the elrepo folks whether/why the above changes are stupid. Alan, Akemi, Dag, ..., are you reading?

We are reading  :-)  But we have not been following up quite well :-(
We would be happy to discuss with you as soon as we digest the
details.

Akemi

ATOM RSS1 RSS2