[Yum-devel] kernel-module plugin ...

[Jack Neely]

On Tue, Jun 07, 2005 at 04:48:46PM -0400, Matthew Miller wrote:
> On Tue, Jun 07, 2005 at 11:42:01PM +0300, Panu Matilainen wrote:
> > Without the ugly uname-hackery the "easy" part stops the minute you try
> > to do an update to a module where the kernel version itself doesn't
> > change: you can't just do a regular update for those packages, you need
> > to instead do a manual "locate and erase a single version of the kernel
> > module package + install a new one." I haven't given the implementation
> > too much thought but I have this funny feeling it's not easy to shoehorn
> > into something sane enough to go into yum proper.
> > But then, the uname-mess isn't "easy" on anybody either :)
> 
> Wait, why would that happen? Just name the module with its own name and its
> own version, and it'll upgrade itself fine.
>

I'm not sure of the exact behavior of RPM here.  If you have 5
openafs-kernel packages installed and you "upgrade" a 6th, which of the
installed packages gets removed?  The higest EVR installed?
 
> My current 'solution' is to just make sure we put an updated openafs kernel
> module package in our repo before or at the same time as a kernel update.
> 
> And our openafs package contains modules for all kernels up to that point.
> I'm not terribly happy with this in theory, but in practice, there have been
> no problems at all. The problem, of course, comes in when the kernel and
> modules are coming from different repositories.

My OpenAFS solution is similar except that I have a openafs-kernel
package for each kernel version.

> 
> Since that's not a problem here, and won't be if we get some kinda
> buildsystem trigger in Extras by the time I feel like OpenAFS is ready to go
> in there, I don't feel an urgent need to come up with a better hack -- I'm
> willing to wait for something really elegant to appear.
> 
> 

I feel that the only thing keeping OpenAFS out of Extras is the lack of
kernel module handling.  Once that problem is hacked out I see no reason
why OpenAFS shouldn't be included.  Our packages are more alike than
not.  I'd most likely approve them for you after the kernel module thing
gets fixed.

But, back on topic, does anyone have any other thoughts on how to handle
kernel modules that might be more sane?

My head contains something like the folowing:

if pkg provides "kernel-modules":
    what kernel version does it require?
    if an installed pkg has the same Name and require the same kernel:
        tag on disk package to be removed in ts
    
    tag new pkg to be installed 

Thoughts?
Jack

> 
> -- 
> Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
> Boston University Linux      ------>                <http://linux.bu.edu/>
> Current office temperature: 80 degrees Fahrenheit.
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89