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

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---

Reply via email to