Hi Axel,
Looking at the yum 2.6.x documentation, it looks like we should be able 
to put it in SL 4.x without any problems.  So I'm using yum 2.6.1, and 
using the remove function, and it's *almost* working correctly.  More on 
that at the end...

Axel Thimm wrote:
> On Fri, Feb 09, 2007 at 12:46:45PM -0600, Troy Dawson wrote:
>> Howdy All,
>> I've been working on the kernel module plugin for SL 4.5.
>> I like Axel's kmdl plugin so much I simply tossed the old plugin and 
>> started fresh with his.  But there were a few points I changed.
>> My goal is to get the plugin to work in the same manner for 
>> kernel-modules for S.L. 3.0.x.
>> I am one step away from that goal, but I'm sort stuck and need some help.
>>
>> So, here is what I changed thus far.
>>
>> 1- changed the format from <module name>-kdml-<kernel> to 
>> kernel-module-<module name>-<kernel>
>> 2- I separated the function kmdls to new_kmdls and old_kmdls, similar to 
>> the new_kernels and old_kernels.
> 
> That was the way it was once.
> 
>> 2a- It now checks to see if there are any new kernels (new_kernels) OR 
>> any new kernel modules (new_kmdls), if there aren't either, than it just 
>> exits.  If there are some, then it collects the list of installed 
>> kernels (old_kernels), and the list of installed kernel modules 
>> (old_kmdls) to process.  The processing is in the same.
>> I did 2a to cut down on the processing time when a user isn't 
>> installing/updating any kernels or kernel modules.
> 
> I think that way you are missing "yum update"s that have new
> kmdls, or kernels/kmdls that are recursively pulled in (I'm not sure
> what exactly you changed, so I'm guessing).
> 

No, it actually does get those.

If there is a new kdml because of a package update (let's say a new 
version of madwifi) then yum see's that and already add's it to the 
update list.  So it is there before we even get to the plugin.  So we 
will see it with the new_kdml function.

A new kernel also kicks it into the checking function.

>> It also makes it so that when a user installs a kernel module, they
>> get the kernel modules for all the kernels they have installed, or
>> are installing.
> 
> That should also had been the case before, or not?
> 

Not during an install.  During an install, it only installed the one 
kernel module, not all the kernel modules for all your kernels.
So if a person wanted to install madwifi, and then reboot into a 
different kernel, they weren't able to do that because it only installed 
one kernel module.
During and upgrade, yes, it would kick in, but not during an install.

> The idea was that
> 
> o "yum update" pulls in all "late" kmdls, e.g. the new kernel was
>   installed the day before and finally someone built the kmdl for it
>   (for Fedora that's the case, as I can only build the kmdl once Dave
>   has pushed the kernel package out the door, for SL one could get both
>   out at the same time)
> 
> o "yum install ... kernel-..." pulls in all kmdls if some other kernel
>   has that kmdl
> 
> o "yum install ... ...-kmdl-..." pulls in all kmdls for sibling
>   kernels, too
> 

This wasn't happening.

> The latter two should also work with implicit kmdls installs, e.g.
> 
> yum install openafs
> 
> and openafs depends on openafs-kmdl, the kmdls for all installed
> (*and* being installed) kernels should be installed.
> 
>> 3- I put alot more bebugging lines.  -d4 is alot more informative, and 
>> -d6 is almost annoying if you have alot of kernels.
>>
>> So, where am I stuck.
>> I'm still stuck with my number one problem.
>> If a user just installs the program that requires a kernel-module, such 
>> as openafs-client, then yum just picks the first kernel-module that 
>> works, whether they have that kernel installed or not.
> 
> That can't be really handled, I also had this issue.
> 
>> I have a solution, but I just can't figure out the details.
>> In the function new_kmdls, after I have found out that there is a kernel 
>> module ready to be installed or updated, I put the module name in my 
>> list.  I can then remove that package from the main list of packages to 
>> be installed.
>>
>> I can remove it because if that package happens to be one for a kernel 
>> we have installed, it will get re-added to the list later on.  If it 
>> isn't for a kernel we have installed, then it needs to be taken off.
> 
> But what if the user explicitely asked for that kmdl and expects the
> kernel to be pulled in, too?
> 

To be honest, if a person is pulling in a kernel module, and expecting 
the kernel to come with it ... well ... that just seems awfully 
backwards to me.  I haven't had one person talk to me about using that 
functionality, but I have had alot complain about it pulling in kernels 
they don't want.

> I think that is a bug in yum, that is difficult to fix after yum has
> done its depsolving because following each decision path you end up
> "reverse engineering" the depsolving.
> 
> The solution would be a hook withing yum's depsolving to be able to
> cast away a wrongly chosen package during depsolving.
> 
> I for one chose to have the unpleasent side-effect of a kernel
> installed too many than to further mess with yum. There is also yet
> another more PITA issue. If "yum update" finds that there is nothing
> conventional to update it never calls the plugin.
> 

Well, the problem of pulling in a new kernel get's complicated if the 
kernel isn't actually there.
Here's the latest scenario.
We just updated openafs to 1.4.1.  So I build kernel modules for all the 
kernels we've released, and sent it out to all releases.
So now, if a user is on SL 4.4, and they do a
   yum install openafs-client
Yum will pick openafs, openafs-client and kernel-module-openafs-2.6.9-34
But kernel-2.6.9-34 isn't in the SL4.4 repository, because SL4.4 shipped 
with 2.6.9-42.0.3.
So yum tried to install the older kernel, but can't because it's not 
there, and then fails.
Yes, I can make it so that SL 4.4 only get's the appropriate kernel 
module for it's kernels, but over the years, that is going to be more 
effort than it is to get yum working right.

> Both of these issues are easier to fix by modifying yum directly,
> within the plugin it's hellish. :/
> 

We're tried modifying yum before, and really really don't want to do 
that again.  The problem is that yum changes so much, that patches don't 
migrate well.

>> But I am unable to take the package off the list of packages to be 
>> installed or updated.  I have tried the remove() command.  But with yum 
>> 2.4.x, the remove function is just a stub, saying it will be written later.
>> I've tried cutting and pasting the code from yum 2.4.6 in, and that 
>> didn't work either.
>> I've tried setting the ts_state to None, but it seemed like it didn't 
>> really stick, it went back after the function.
>>
>> Any ideas?
>>
>> Thanks
>> Troy

So, how did the remove function work?
Well, with some kernel modules, it worked great, with some, not so great.

If I do a
   yum install madwifi
Yum correctly see's that it needs a kernel module, picks the earliest 
one (for a kernel I don't have installed) and put's it on the list of 
things to install.
The plugin comes along, see's that we're doing something with kernel 
modules for madwifi, notes that we're doing madwifi, then takes the 
kernel module off the list.
It then goes through the list of installed kernel's and available kernel 
modules, and correctly gives me only the kernel modules for which I have 
a kernel installed.
It then correctly tries to install the right stuff.
I was excited ... until I tried openafs

If I do a
   yum install openafs-client
It does the same steps.  It picks a kernel-module for a kernel I don't 
have.  We note that we have openafs, and remove that kernel module from 
the list.  We go through the list of kernels and modules and setup 
everything correctly.
And then Yum goes back and tries to resolve the dependancies for the 
kernel module that we took off the list.


Here's the two outputs

# yum install madwifi
...
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package madwifi.i686 0:0.9.6.0-1 set to be updated
--> Running transaction check
--> Processing Dependency: kernel-module-madwifi >= 0:0.9.6.0 for 
package: madwifi
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package kernel-module-madwifi-2.6.9-42.0.3.EL.i686 0:0.9.6.0-2.SL4 
set to be updated
--> Running transaction check
Beginning Kernel Module Plugin
---> Package kernel-module-madwifi-2.6.9-42.0.3.EL remove from update list
---> Package kernel-module-madwifi-2.6.9-42.0.8.EL.i686 0:0.9.6.0-2.SL4 
set to be installed
---> Package kernel-module-madwifi-2.6.9-42.0.3.ELsmp.i686 
0:0.9.6.0-2.SL4 set to be installed
---> Package kernel-module-madwifi-2.6.9-42.0.8.ELsmp.i686 
0:0.9.6.0-2.SL4 set to be installed
Finished Kernel Module Plugin
--> Populating transaction set with selected packages. Please wait.
---> Package kernel-module-madwifi-2.6.9-42.0.8.EL.i686 0:0.9.6.0-2.SL4 
set to be updated
---> Package kernel-module-madwifi-2.6.9-42.0.3.ELsmp.i686 
0:0.9.6.0-2.SL4 set to be updated
---> Package kernel-module-madwifi-2.6.9-42.0.8.ELsmp.i686 
0:0.9.6.0-2.SL4 set to be updated
--> Running transaction check

Dependencies Resolved

 ============================================================================
  Package                 Arch       Version          Repository        Size
 ============================================================================
Installing:
  kernel-module-madwifi-2.6.9-42.0.3.ELsmp  i686       0.9.6.0-2.SL4 
sl-base           181 k
  kernel-module-madwifi-2.6.9-42.0.8.EL  i686       0.9.6.0-2.SL4 
fermi-errata      181 k
  kernel-module-madwifi-2.6.9-42.0.8.ELsmp  i686       0.9.6.0-2.SL4 
fermi-errata      181 k
  madwifi                 i686       0.9.6.0-1        sl-base 
  24 k


# yum install openafs-client
...
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package openafs-client.i386 0:1.4.1-0.11.SL set to be updated
--> Running transaction check
--> Processing Dependency: openafs = 1.4.1 for package: openafs-client
--> Processing Dependency: openafs-kernel for package: openafs-client
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package kernel-module-openafs-2.6.9-34.EL.i686 0:1.4.1-0.11.SL set 
to be updated
---> Package openafs.i386 0:1.4.1-0.11.SL set to be updated
--> Running transaction check
--> Processing Dependency: /boot/vmlinuz-2.6.9-34.EL for package: 
kernel-module-openafs-2.6.9-34.EL
Importing additional filelist information
--> Finished Dependency Resolution
Beginning Kernel Module Plugin
---> Package kernel-module-openafs-2.6.9-34.EL remove from update list
---> Package kernel-module-openafs-2.6.9-42.0.8.EL.i686 0:1.4.1-0.11.SL 
set to be installed
---> Package kernel-module-openafs-2.6.9-42.0.3.ELsmp.i686 
0:1.4.1-0.11.SL set to be installed
---> Package kernel-module-openafs-2.6.9-42.0.8.ELsmp.i686 
0:1.4.1-0.11.SL set to be installed
Finished Kernel Module Plugin
--> Populating transaction set with selected packages. Please wait.
---> Package kernel-module-openafs-2.6.9-42.0.8.ELsmp.i686 
0:1.4.1-0.11.SL set to be updated
---> Package kernel-module-openafs-2.6.9-42.0.8.EL.i686 0:1.4.1-0.11.SL 
set to be updated
---> Package kernel-module-openafs-2.6.9-42.0.3.ELsmp.i686 
0:1.4.1-0.11.SL set to be updated
--> Running transaction check
--> Processing Dependency: /boot/vmlinuz-2.6.9-34.EL for package: 
kernel-module-openafs-2.6.9-34.EL
--> Finished Dependency Resolution
Error: Requiring package kernel-module-openafs-2.6.9-34.EL-1.4.1-0.11.SL 
not in transaction set                        nor in rpmdb


Now that I am about to send this, I'm seeing that it's doing some extra 
dependancies before it get's to the kernel module plugin section.  I'm 
going to look at that some more.  But I'll send this e-mail anyway.
Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________