Control: retitle -1 linux-libc-dev: squeeze upgrade issue: linux-libc-dev introduces multiarch headers before compiler upgrade
Control: reassign -1 linux-libc-dev

Dominic Hargreaves <dom@earth.li> writes:

> at the point I saw this error (at the and of an apt-get upgrade),
> neither libc6-dev nor gcc-* had been upgraded. dkms had been upgraded to
> 2.2.0.3-1.1. The other possibly-relevant packages upgraded at that point
> were autoconf, autoconf2.13, automake, automake1.9, dpkg-dev,
> linux-base, linux-libc-dev; could the newer dpkg-dev have cause dkms to
> attempt to use multi-arch paths too soon?

Ah, aha! It's not libc6-dev, it's linux-libc-dev.

windlord:~> dpkg -L linux-libc-dev | grep errno.h
/usr/include/linux/errno.h
/usr/include/i386-linux-gnu/asm/errno.h
/usr/include/asm-generic/errno.h

Upgrading linux-libc-dev would have moved errno.h into the multiarch path,
but your gcc didn't know to look there. And indeed, linux-libc-dev
doesn't have any Breaks or other relations to try to force the compiler to
be upgraded.

I forgot that set of headers was in the linux-libc-dev package instead.
I'll reassign this bug to linux-libc-dev.

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. I believe linux-libc-dev needs the same Breaks logic as
libc6-dev, namely something like:

Breaks: gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 4.6.0-12)

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d322c3q5.fsf@windlord.stanford.edu">http://lists.debian.org/87d322c3q5.fsf@windlord.stanford.edu

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.

> I believe linux-libc-dev needs the same Breaks logic as
> libc6-dev, namely something like:
>
> Breaks: gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 4.6.0-12)

That sounds plausible, yes.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120903211640.GT29217@decadent.org.uk">http://lists.debian.org/20120903211640.GT29217@decadent.org.uk

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871uiiajfk.fsf@windlord.stanford.edu">http://lists.debian.org/871uiiajfk.fsf@windlord.stanford.edu