Your message dated Sun, 30 Apr 2017 20:34:15 +0200
with message-id <20170430183415.5zrkpb7okw4hr...@aurel32.net>
and subject line Re: Bug#861518: libc6-dev: The newest libc6-dev (2.24-10)
badly depends on kernel, particularly linux-libc-dev (>= 4.9.18-1)
has caused the Debian Bug report #861518,
regarding libc6-dev: The newest libc6-dev (2.24-10) badly depends on kernel,
particularly linux-libc-dev (>= 4.9.18-1)
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.)
--
861518: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861518
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.24-10
Severity: important
Dear Maintainer,
* What led up to the situation?
I tried to install libc6-dev on my armhf embedded hardware.
Its not possible, because dependencies are not met.
Because the newest libc6-dev depends particularly on linux-kernel
(>= 4.9.18-1), and this is an error, at least I hope its not intentional.
Because many embedded armhf devices use older kernels, 4.1 , 4.4 ... so on
, it depends on BSP what you can get from the HW vendor. Usually they have no
4.9 or any near to mainline kernel.
So they have no linux-libc-dev (>= 4.9.18-1)
So they cant install libc6-dev (2.24-10)
So actually they can't develop.
Earlier libc6-dev (<=2.24-9) depended only on linux-libc-dev (without version),
so it was installable.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64
(x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.24-10
ii libc6 2.24-10
ii linux-libc-dev 4.9.18-1
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc <none>
ii manpages-dev 4.10-2
-- no debconf information
--- End Message ---
--- Begin Message ---
On 2017-04-30 18:03, Laci Tele wrote:
> Hi Aurelien,
>
> On Sun, Apr 30, 2017 at 2:55 PM, Aurelien Jarno <aurel...@aurel32.net>
> wrote:
>
> > control: tag -1 + moreinfo
> > thanks
> >
> > On 2017-04-29 18:49, Laci Tele wrote:
> > > Package: libc6-dev
> > > Version: 2.24-10
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > >
> > > * What led up to the situation?
> > >
> > > I tried to install libc6-dev on my armhf embedded hardware.
> > > Its not possible, because dependencies are not met.
> > > Because the newest libc6-dev depends particularly on linux-kernel
> > > (>= 4.9.18-1), and this is an error, at least I hope its not intentional.
> >
> > Not it doesn't depends on the latest kernel. It depends on the latest
> > kernel *headers* which are provided by linux-libc-dev.
> >
> >
> ????
> And the package linux-libc-dev provided by the linux kernel. So libc6-dev
> depends on linux kernel (>= 4.9.18-1), via linux-libc-dev (>= 4.9.18-1)
It is indeed provided by the linux source package, but that is not
relevant here. It doesn't mean you need to run the same kernel.
> > > Because many embedded armhf devices use older kernels, 4.1 , 4.4 ... so
> > on
> > > , it depends on BSP what you can get from the HW vendor. Usually they
> > have no 4.9 or any near to mainline kernel.
> >
> > Yes, that's something known. libc6 requires at least a 3.2 kernel on
> > most architectures, and 2.6.32 on i386 and amd64.
> >
> > > So they have no linux-libc-dev (>= 4.9.18-1)
> >
> > You can install linux-libc-dev (>= 4.9.18-1) even if you're embedded
> > device uses a 4.1 or 4.4 kernel. It's provided in the Debian archive.
> >
>
> I don't want to install linux-libc-dev (>= 4.9.18-1) which one belongs to
> the kernel (>= 4.9.18-1) , but I have an installed a 4.1.15-2 kernel and
> it's own linux-libc-dev (4.1.15-2) package.
It is you choice, but then that is not a bug.
> And I have mentioned that, this dependency is a new thing, in the whole
> history of libc6-dev (until 2.24-10) it depended only a versionless
> linux-libc-dev (linux header files in general without specific version).
> This new, few days old dependency breaks the things badly.
> Is it necessary indeed ?
Yes, it's a new dependency that has been introduced in version
2.24-1. As explained in bug#834706, it is needed to make sure that all
the defines in <bits/syscall.h> are pointing to an existing value in
<asm/unistd.h>. See bug#834706 for more details.
> >
> > > So they cant install libc6-dev (2.24-10)
> > > So actually they can't develop.
> >
> > Please try to install libc6-dev and linux-libc-dev from stretch or sid.
> > If it fails to install, please provide the error message from apt,
> > aptitude or dpkg showing the issue.
> >
>
> It doesn't fail, its possible to do that, but its a mistake, its an error.
> Obviously using a header which belongs to a much newer kernel than the
> current one is not so healthy. The things declared in the linux headers
> (>= 4.9.18-1) might or might not exist in the working kernel 4.1.15 .
> Your method seemingly works, but you just sow the seeds of latent and hard
> to detect errors in the future. I can't imagine that, if a binary was built
> based on a mismatching header if that worked perfectly in a totally
> different and older environment. Maybe if you use color codes, of some
> version independent defines only from that header you used. But that is
> very unlikely.
That's definitely not how things work. Userland should detect at runtime
if some features (i.e. syscalls) are available or not. This is done up
to a certain limit, that's why for example Debian Stretch requires at
least a 3.2 kernel on most architectures or 2.6.32 on amd64 and i386.
This is the reason why it is possible to use Debian Stretch with a 4.1
kernel, as anyway most binaries from this release have been built
against the 4.9 kernel headers. This also allow you to use chroots from
older or newer release or even from a different distribution than
Debian. Finally this also allow to upgrade from example from Jessie to
Stretch, without having to install a newer kernel first.
> If your binary expects something at runtime, because it was declared so at
> build-time, and it can't find it because it doesn't exist, that will be a
> bad error. This is my opinion.
Then that's a bug of your binary which should do runtime detection of
the available syscalls. In that case the bug should be reported against
that binary.
> And developers must be 100% disciplined about this. The "its possible" and
> "it seems good and working" that is not enough.
That way of doing doesn't provide any flexibility. It impose that the all
binaries have been built against the running kernel, that is why Linux
distributions do not work that way.
I am therefore closing this bug. Don't hesitate to reopen it if you
finally decided to install linux-libc-dev (>= 4.9.18-1) and you find it
causes some issues.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- End Message ---
