Your message dated Thu, 01 Dec 2016 19:46:58 +0000 with message-id <1480621618.16599.103.ca...@decadent.org.uk> and subject line Re: Bug#846513: linux-libc-dev possibly needs dependency on corresponding linux-image has caused the Debian Bug report #846513, regarding linux-libc-dev possibly needs dependency on corresponding linux-image to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 846513: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846513 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: linux-libc-dev Version: 4.7.6-1 Severity: normal Dear Maintainer, =================================================================================== I'm running linux-image-4.7.0-1-686-pae which is pinned to version 4.7.6-1 (see below). However, linux-libc-dev can be upgraded to version 4.8.7-1 without also upgrading the linux image, as linux-libc-dev does not depend on it. It would seem this could cause inconsistencies with binaries built on the 4.7.6-1 image but using the headers for 4.8.7-1. Should linux-libc-dev depend on the linux image it corresponds to? => apt-cache policy | sort | grep linux ... linux-headers-4.7.0-1-686-pae -> 4.7.6-1 with priority 1001 linux-headers-4.7.0-1-common -> 4.7.6-1 with priority 1001 linux-headers-686-pae -> 4.7+75 with priority 1001 ... linux-image-4.7.0-1-686-pae -> 4.7.6-1 with priority 1001 linux-image-686-pae -> 4.7+75 with priority 1001 linux-kbuild-4.7 -> 4.7.6-1 with priority 1001 linux-libc-dev -> 4.7.6-1 with priority 1001 => apt-cache policy linux-libc-dev linux-libc-dev: Installed: 4.7.6-1 Candidate: 4.7.6-1 Version table: 4.8.7-1 500 500 http://debian.lcs.mit.edu/debian testing/main i386 Packages *** 4.7.6-1 1001 500 http://snapshot.debian.org/archive/debian/20161017 testing/main i386 Packages 500 copy:/usr3/Installs/DEB ./ Packages 100 /var/lib/dpkg/status 4.7.5-1 500 500 http://snapshot.debian.org/archive/debian/20161005 testing/main i386 Packages =================================================================================== -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.7.0-1-686-pae (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
--- End Message ---
--- Begin Message ---On Thu, 2016-12-01 at 13:53 -0500, js wrote: > Package: linux-libc-dev > Version: 4.7.6-1 > Severity: normal > > Dear Maintainer, > > ===================================================================== > ============== > > I'm running linux-image-4.7.0-1-686-pae which is pinned to version > 4.7.6-1 (see below). > > However, linux-libc-dev can be upgraded to version 4.8.7-1 without > also upgrading > the linux image, as linux-libc-dev does not depend on it. > > It would seem this could cause inconsistencies with binaries built on > the 4.7.6-1 image > but using the headers for 4.8.7-1. linux-libc-dev defines the kernel's userland API (and ABI), which is intended to always be backward-compatible. So there should be no inconsistency. What could happen is that a program's build-time feature tests detect a kernel feature that won't be available at run-time. But that would already be a bug in that program, since there's nothing that forces users of packages from testing to run the kernel version in testing. > Should linux-libc-dev depend on the linux image it corresponds to? There is no requirement that the kernel is installed within the same system (chroot installations, containers and some paravirtualised environments don't). Nor is there a requirement that a Debian system runs on oen of Debian's packaged kernels. Besides, if a particular kernel version is installed, that doesn't mean that it's running. So when a package does depend on a particular minimum kernel version, it can't use package relations to ensure that - it has to use a run- time test. The same is true for kernel features that are optional. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson
Description: This is a digitally signed message part
--- End Message ---