On Thu, 2003-04-24 at 09:29, Ed Brown wrote: > On Wed, 2003-04-23 at 23:41, seth vidal wrote: > > > > > > > I am not sure. I have to look at it. I am not sure of the consequences of having > > > 2 sets of modules in the kernel with different names. I suppose it would not > > > matter as long as the correct modules got loaded. > > > > > > > you'd have to rebuild it with each kernel update but <shrug> that's not > > > > very hard. > > > > > > I already have to rebuild on kernel upgrade, so this is not any additional work. > > > It is for this reason that the kernels on these machines only get upgraded if > > > there are remote exploits or stability problems. They are remote unattended > > > machines with no local users. Some of them are up 8 or 9 months. No stability > > > problems there. :-) > > > > This is something I've discussed with others before. > > > > something in yum or any update tool that allow you to spawn off an > > arbitrary script when pkgx gets updated/installed/removed > > > > so if kernel gets updated/installed then something spawns off a "rebuild > > this module" script. So the next time the system boots that module is > > all happy. > > > > -sv > > > > This reference is rather dated, and I haven't ever used them, but if > triggers are still supported, then your custom module rpm could do this > itself. See: > http://www.rpm.org/support/RPM-Changes-6.html 2 problems with triggers 1. they're godawful messy 2. that would mean modifying every pkg you wanted to add a trigger to I was thinking: have yum have a separate config file that maintained a list of commands vs lists of pkg names that way it could be more trivially updated. -sv
