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

[Phil Perry]

Farkas Levente wrote:
> On 08/07/2009 01:58 PM, Dag Wieers wrote:
>>    - we want it to be able to package multiple kernel modules (for 
>> different
>>      kABI versions) for all the main RHEL releases (8.el5, 53.el5, 
>> 92.el5,
>>      128.el5)
> 
> what's the plan for this different packages? or...
> 

Dag's idea was a mechanism to package multiple modules in one package 
built against each base kernel... from 5.0, 5.1, 5.2... etc as the kABI 
is mostly stable within a release but sometimes breaks between releases.

>> We could use help from the community with everything we are currently
>> lacking and I would prefer that we focus on enabling users to help us,
>> rather than trying to do everything ourselves.
>>
> 
> here's my first patch to the scripts and a few comments:
> - kmp_add_requires and kmp_add_buildrequires are similar to other kmp_ 
> variable so you can add extra requires and buildrequires.
> - in the spec file some trivial fix and change "+-$kvariant" to 
> "+$kvariant" since this how the kernel module dir looks like.
> 
> is this acceptable for you?
> than i'll patch a few kmod to use this new schema.
> 
> anyway wouldn't it be useful to create a new packages eg: kmod-devel 
> which contains this/one common kmodtool (i prefer common kmodtool over 
> all kmod packages contains it's own kmodtool) and the template files.
> 

I agree, however the main reason for currently shipping separate 
kmodtool scripts with each package is that some packages need to be 
updatable (whereas others don't), and this is achieved via a Provide in 
kmodtool, and some packages have custom Requires, again also implemented 
in kmodtool. I see no way to work around this with the current distro 
kmodtool.

We have a fundamental choice here - either we stick with and work with 
the tools Red Hat have provided (kmodtool in this case) and make as few 
and unobtrusive changes as possible, or we completely rewrite kmodtool 
to make it do what we want. In terms of the packages we currently 
provide, we have presently chosen the former... Dag has been talking 
with Jon Masters et al., about the later.