[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#686436: openafs-modules-dkms: Does not build with squeeze kernel: error: asm/errno.h: No such file or directory



Ben Hutchings <ben@decadent.org.uk> writes:
> On Mon, Sep 03, 2012 at 12:21:06PM -0700, Russ Allbery wrote:
> [...]
>> linux-libc-dev maintainers, when upgrading to squeeze, there is
>> currently nothing preventing linux-libc-dev from being upgraded to a
>> version that uses multiarch paths in advance of upgrading any compiler
>> to understand those paths, which results in a broken C compilation
>> environment.  In this case, this affected dkms, since dkms runs a
>> compiler from postinst scripts.

> linux-libc-dev is of course not used to build kernel modules.  But
> perhaps openafs also needlessly rebuilds userland code every time the
> kernel is upgraded.

The OpenAFS build system is rather complicated since it supports a ton of
different kernels, not just Linux.  Part of it involves building a small C
program which, in turn, is used to generate part of the build system.
It's possible in theory to eliminate that by shipping the results of the
pre-constructed configuration, but it either would mean that
openafs-modules-dkms could not be arch: all, since that's how OpenAFS
handles configuring for different kernel architectures, or I'd have to
invent some other way of choosing between a bunch of prebuilt
configurations (and find a way of maintaining them with each upstream
change).

I've played around with a variety of different ways of handling this, and
this method of leaving in the small userspace C binary for configuration
handling was the cleanest (not to mention the one that's supported by
upstream, which has an official target for generating a minimal source
tree for just the kernel module that includes that configuration
handling).

Anyway, I think the DKMS involvement is somewhat accidental and one can
arrive at other problems than just DKMS postinst scripts by doing a
partial upgrade.  The OpenAFS package just has a peculiarity that caused
us to stumble across this.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: