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

[Phil Perry]

Farkas Levente wrote:
> On 08/29/2009 06:05 PM, Phil Perry wrote:
>>> 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.
>> I don't see where this is going? I don't see how we can do anything
>> other than ship a custom kmodtool with each package. Even if you have a
>> common custom kmodtool, you still have to distribute it, so it needs to
>> be a Requires (or BuildRequires), and those need to go in kmodtool so it
>> has to be in the SRPM package.
> 
> no you can use the same kmodtool but set different environment variable 
> before call kmodtool. ok somehow have to ship the common kmodtool, but 
> that's a different story.
> 
>>> - in the spec file some trivial fix and change "+-$kvariant" to
>>> "+$kvariant" since this how the kernel module dir looks like.
>>>
>> "+-$kvariant" looks correct to me; "+$kvariant" looks like the symlink:
>>
>> $ ll /usr/src/kernels/
>> total 124
>> drwxr-xr-x 19 root root 4096 Jul  4 12:35 2.6.18-128.1.16.el5-x86_64
>> drwxr-xr-x 19 root root 4096 Jul  4 12:35 2.6.18-128.1.16.el5-xen-x86_64
>> lrwxrwxrwx  1 root root   30 Jul  4 12:35 2.6.18-128.1.16.el5xen-x86_64
>> ->  2.6.18-128.1.16.el5-xen-x86_64
>> drwxr-xr-x 19 root root 4096 Jul 16 13:32 2.6.18-128.2.1.el5-x86_64
>> drwxr-xr-x 19 root root 4096 Jul 16 13:32 2.6.18-128.2.1.el5-xen-x86_64
>> lrwxrwxrwx  1 root root   29 Jul 16 13:32 2.6.18-128.2.1.el5xen-x86_64
>> ->  2.6.18-128.2.1.el5-xen-x86_64
>> drwxr-xr-x 19 root root 4096 Aug  6 13:32 2.6.18-128.4.1.el5-x86_64
>> drwxr-xr-x 19 root root 4096 Aug  6 13:32 2.6.18-128.4.1.el5-xen-x86_64
>> lrwxrwxrwx  1 root root   29 Aug  6 13:32 2.6.18-128.4.1.el5xen-x86_64
>> ->  2.6.18-128.4.1.el5-xen-x86_64
>> drwxr-xr-x 19 root root 4096 May  5 00:10 2.6.18-128.el5-x86_64
>> drwxr-xr-x 19 root root 4096 May  5 00:09 2.6.18-128.el5-xen-x86_64
>> lrwxrwxrwx  1 root root   25 May  5 00:09 2.6.18-128.el5xen-x86_64 ->
>> 2.6.18-128.el5-xen-x86_64
>> drwxr-xr-x 18 root root 4096 Aug 24 13:24 2.6.18-53.el5-x86_64
>> drwxr-xr-x 18 root root 4096 Jul  4 12:21 2.6.18-8.el5-x86_64
>> drwxr-xr-x 19 root root 4096 Jul  4 12:21 2.6.18-8.el5-xen-x86_64
>> lrwxrwxrwx  1 root root   23 Jul  4 12:21 2.6.18-8.el5xen-x86_64 ->
>> 2.6.18-8.el5-xen-x86_64
>> drwxr-xr-x 18 root root 4096 Aug 24 13:20 2.6.18-92.el5-x86_64
>> drwxr-xr-x  4 ajb  ajb  4096 May  5 00:00 2.6.18-92.el5-xen-x86_64
> 
> ops this was right, i just rewrite all of my spec file from 
> ${kvariant:+-$kvariant} to ${kvariant:+$kvariant} since eg. kernel 
> modules in /lib/modules/2.6.18-128.7.1.el5PAE and not in 
> /lib/modules/2.6.18-128.7.1.el5-PAE and if the module has not standard 
> "make modules_install you've to install it into:
> $RPM_BUILD_ROOT/lib/modules/%{kverrel}${kvariant:+$kvariant}/extra/%{kmod_name}
> where you've not to use "-". that's why i think it's better to use 
> anywhere the none "-" version.
> 

OK, I see what you are saying, but we have used it in reference to 
/usr/src/kernels, not /lib/modules. But yes you are correct, if you are 
not using the modules_install Makefile target, but are manually 
performing an install to $RPM_BUILD_ROOT/lib/modules then 
%{kverrel}${kvariant:+$kvariant} is the correct syntax.

I guess the confusion comes from upstream using ${kvariant:+$kvariant} 
in /lib/modules and ${kvariant:+-$kvariant} in /usr/src/kernels.

>> Our SPEC template is drawn from the upstream work of Jon Masters as part
>> of the Red Hat Driver Update Programme:
>>
>> http://dup.et.redhat.com/
>>
>> and specifically template examples here:
>>
>> http://www.kerneldrivers.org/RedHatKernelModulePackages
> 
> i already read it last week, but as you don't use the macros shipped by 
> rh's macros, you can change even more.
> 
>>> 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.
>>>
>> ...and how would package kmod-foo specify kmod-devel as a build
>> requirement if it has no kmodtool script? You still have to ship
>> kmodtool in each SRPM (if you're not going to use
>> /usr/lib/rpm/redhat/kmodtool) so you may as well just make the required
>> modifications therein as we currently do.
> 
> kmod-devel can contains one common kmodtool eg:
> /usr/lib/rpm/kmodtool or /usr/libexec/kmod/kmodtool or anything and all 
> kmod-foo buildrequires kmod-devel.
> 
> 

OK, I see how that could work.

What I don't get is the desire to move to a single custom kmodtool 
script. Sure I can see it's kind of an elegant solution, but what does 
it offer over and above what we already have?

My main objection is that it would require more modification (diversion) 
  from the distro file than we presently have and I'd like to stay as 
close as possible to the tool upstream provides.

It would be easy to completely rewrite kmodtool to have it do exactly 
what we want, but I believe that rather than us do this, this is 
something that should get fed back into the upstream development effort 
so it can filter back down stream for us (and everyone else) to use.

To that extent, I know Jon Masters is keen to discuss with end users of 
the Driver Update Programme how it can best be improved, and Dag had 
some ideas around this area and was trying to set up some discussions. 
I'm not sure if those discussions actually started yet, so now might be 
a good time for you to get involved with that and put forward your point 
of view as to what you'd like to see from kmodtool going forward. I'm 
sure when he's around, Dag will be able to give you more details :-)

How about we start a wishlist - things we'd like kmodtool to be able to 
do that it currently can't do. I'll start it off...

1. Have a mechanism for specifying if a kmod package should be updatable 
by yum (Provides: kernel-modules) from the command line.

2. define Requires and Provides on the command line.

3. define a custom list of %files from the command line.

4. Provide a mechanism to deal with kABI breakage.