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

[Farkas Levente]

On 08/29/2009 10:07 AM, Phil Perry wrote:
> 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.

id they are in one package how can we (and the running kernel) 
distinguish between them?
may be if the modules are in different subpackage each subpackage 
provide a common name and also obsoletes it (to prevent to install 
multiple subpackage) and the main packages requires the common name (ie. 
one subpackage). we do something similar eg:

kmod-foo
Requires(pre): kmod-foo-module = %{version}

kmod-foo-5.0
Provides: kmod-foo-module = %{version}
Obsoletes: kmod-foo-module = %{version}
...

>>> 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.

but we still can make a new updated kmodtool verison and that kmodtool 
can be common. as i wrote the custom provide and requires can be added 
to 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.

you mean the /usr/lib/rpm/redhat/macros's kernel_module_package?
and we try to push it into rhel 6. can we know the result of that talk?

-- 
   Levente                               "Si vis pacem para bellum!"