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

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

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

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?

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.

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

> 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
> p.s.  The remove function is in transactioninfo.py.  The new code is
>     def remove(self, pkgtup):
>         """remove a package from the transaction"""
>         if not self.pkgdict.has_key(pkgtup):
>             self.debugprint("Package: %s not in ts" %(pkgtup,))
>             return
>         for txmbr in self.pkgdict[pkgtup]:
>             txmbr.po.state = None
> 
>         del self.pkgdict[pkgtup]
>         self.changed = True
> 
> 



-- 
Axel.Thimm at ATrpms.net