Two questions about FC1 kernel upgrades

[Panu Matilainen]

On Wed, 2004-01-14 at 13:39, Dag Wieers wrote:
> On Wed, 14 Jan 2004, Panu Matilainen wrote:
> 
> > On Wed, 14 Jan 2004, Dag Wieers wrote:
> > 
> > > On Tue, 13 Jan 2004, Daniel Robitaille wrote:
> > > 
> > > > 1) Since I installed FC1 just before Christmas, I have had to do 4
> > > > kernel upgrades in 3 weeks.  Is that an anomalous period, or it's
> > > > always going to be like that in the Fedora world?  I don't remember so many
> > > > kernel updates in a short time like this with RHL8/9. Or I'm getting
> > > > what I'm paying for? :)
> > > > 
> > > >  Dec 24 14:48 vmlinux-2.4.22-1.2135.nptl 
> > > >  Jan  6 17:50 vmlinux-2.4.22-1.2138.nptl
> > > >  Jan  7 23:19 vmlinux-2.4.22-1.2140.nptl
> > > >  Jan 13 20:40 vmlinux-2.4.22-1.2149.nptl
> > > 
> > > Also a huge pain for kernel-module packagers. For each kernel release I'm 
> > > doing about 14 packages for 4 archs and 4 distributions, for smp and up.
> > > 
> > > That's about 448 kernel-module packages for each new kernel. It takes 
> > > more than 24 hours to do ;(
> > 
> > Ouch...
> > 
> > Since this came up, while more a -devel topic, packaging kernel modules 
> > into rpm's the way all the 3rd party repos are doing now is really a road 
> > to madness. Not only because the endless rebuild requirement but also end 
> > user transparency.. the current methods of upgrading those packages are by 
> > no means perfect :(
> 
> Yes, I yesterday told someone to install some kernel-module for 
> 1.2140.nptl and although the package requires the kernel to be installed. 
> Apt silently installed it without matching this requirement, I was 
> wondering why that was. I understand that it doesn't install the kernel 
> package automatically, but it could/should protest or give at least 
> feedback that one should install that package too.

It all depends on what sort of dependency you have in there. 
"Requires: kernel = 2.4.22-1.2140.nptl-untilcowboyscomehome" will still
match *any* kernel with version 2.4.22 because of "Provides: kernel =
%{version}" in RH kernels (and that's a feature of rpm, not apt). Only
way to get the dependency kinda correct with stock RH kernels is to
require a filename which includes `uname -r`, eg 
"Requires: /boot/vmlinuz-2.4.22-1.2140.nptl" - then apt will do the
right thing when installing a new kernel-module package for some version
(== automatically pull in the matching kernel package)

> 
> I didn't tested it with Yum though.
> 
>  
> > Have you looked at "Dynamic Kernel Module Support"? 
> > http://lists.us.dell.com/pipermail/linux-poweredge/2003-March/023795.html
> > (I haven't yet but intend to..) The described intent in the link above is 
> > actually for the reverse situation compared to what we're talking now but 
> > I think it could be used for our purposes just as well... (assuming it 
> > works and has no further complications of its own :)
> 
> I thought DKMS would require building modules on the end-users system. 
> Although a viable alternative, I'm not interested in a solution that 
> forces a user to compile stuff (even when done automatically).

Yup, it requires you to build modules on the users system. It's not
optimal either :(

> 
> It would be nice to have some standard way for (external) kernel modules 
> to be compiled so that it can be automated much easier. (Makefile 
> variables to define the kernel-version or kernel-dir). I guess DKMS 
> requires something like that too.
> 
> OT: In my opinion it's better for end-users (or production systems) not to 
> have a compiler (and development-packages) installed. Either to force 
> sysadmins to properly package (and test) the software they need, or to 
> avoid/discourage end-users to start downloading tarballs and 
> compiling/installing stuff.

I agree, except that the current rate of kernel updates makes this thing
truly insane for both packagers and users. I guess with a bit of Lua
magic apt could be told to handle kernel-module packages semi-sanely, eg
if you have kernel-module-foo-`uname -r` installed then don't upgrade
the kernel either until there's kernel-module-foo-`uname -r of new
kernel` available, just haven't had time to check how much work that
would actually be (never mind doing anything about it) 

Anyway at least I would be perfectly happy with external kernel modules
just automatically getting recompiled when rebooting to a new kernel but
maybe that's just me :)

	- Panu -