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) > > 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. 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 ? > > > 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. 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. And developers must be 100% disciplined about this. The "its possible" and "it seems good and working" that is not enough. > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net > Regards, Laci
