[elrepo-devel] a few comment about elrepo's packages

[Phil Perry]

Farkas Levente wrote:
> On 08/06/2009 05:13 PM, Phil Perry wrote:
>> Farkas Levente wrote:
>>> On 08/05/2009 01:31 PM, Phil Perry wrote:
>>>>> the best would be some kind of packaging howto with comment and
>>>>> templates which can be used in all kmod packages.
>>>>> regards
>>>>>
>>>> We have template files for Makefile, kmodtool and SPEC. You can see
>>>> these from any recent package. I agree that it would be a good idea to
>>>> document these on the wiki :)
>>> ok than in short can i get the latest Makefile, kmodtool and SPEC
>>> template and spec?
>>> thanks.
>>>
>> Sure, I'll send you the files off list :)
>>
>> They are actually on the Wiki, but I'm not sure they're visible to guests:
>>
>> http://elrepo.org/tiki/kmodspec
>> http://elrepo.org/tiki/kmodtool
>> http://elrepo.org/tiki/Makefile
>>
>> If you're interested in contributing (and/or maintaining) packages then
>> we can get you set up with an account.
> 
> can i get an account?
> i'd like to search through all packages kmodtool and see the differences...
> 

We need to think what we are going to do with respect to accounts. At 
the moment I think we only have admin accounts, and obviously not 
everyone needs to be an admin.

Akemi - can we set up an account type for contributors/packagers? 
Something with unrestricted viewings and that can create and modify content?

With respect to kmodtool, we (well, Alan mostly) have now updated the 
vast majority of packages to use the new kmodtool template. We don't 
have a centralized build system so the only way to look/diff kmodtool 
for all packages is to pull the SRPMs.

In summary, the main differences over this distro shipped kmodtool are:

1. Provides:         kabi-modules = ${verrel}${variant}

kmodtool normally has a Provide for kernel-modules that prevents yum 
from updating kmod packages. However, for a kABI tracking kmod package, 
updating (rather than installing kernel dependent versions) makes sense 
so we changed the Provide to kabi-modules to facilitate this behaviour 
in yum.

However, the kABI does occasionally change, and if we know (or suspect) 
the kABI might break for a particular package then, at present, we don't 
set kmodtool to update and would rather build and issue a new package 
built against the newest base kernel. An example of this is the 
video4linux package.

2. Blacklisting

We provide a standardised mechanism within kmodtool for blacklisting 
modules where needed. Alan would be able to give you an example of a 
modules that requires this, but I believe some of the network controller 
driver modules do.

3. override .conf

We provide a mechanism from within kmodtool (and the package spec file) 
to allow rpm to manage the modules override .conf file in /etc/depmod.d/ 
through %files.

and that's basically it. Our philosophy has very much been to work with 
the tools Red Hat provides us as far as possible. The changes we make to 
kmodtool above are as minimalistic and non-intrusive as possible, and 
implemented in such a way as to be universal for all packages.

Our hope is that kmodtool will grow to become more flexible in RHEL6, 
but I doubt Red Hat will no make significant changes for 5.x.

One of the biggest issues we have at present is how to handle packages 
where the kABI breaks. In an ideal world the kABI would always be 
stable, but experience has taught us that doesn't happen. Dag has 
suggested a mechanism for packaging multiple versions of the same 
module, built against each base kernel for where there is kABI 
breakages. The present solution is to revert to building kernel (series) 
dependent packages to support older kernels.