RE: Dependencies of linux-headers-<arch> packages
Thanks for the detailed response.
> > This becomes an issue when cross-compiling kernel modules for other target
> instead of "target" you probably mean "host" architecture. The GNU
> terminology is "host" for the architecture you build for and "target" for the
> architecture that the compiler you build compiles binaries for. Since you are not
> building a compiler you want to use either host or build architecture. The
> terminology is explained in the dpkg-architecture man page.
Right... thanks for the hint.
I just mixed that up, because the terminology in the "embedded world" (e.g. yocto) is different (target=GNU host, host=GNU build).
> > The linux-headers packages cannot be co-installed due to the not co-
> installable cpp-<x> packages.
> > By that, cross-compilation of kernel modules for other Debian targets is
> currently not possible (at least without removing the hosts cpp infrastructure).
> > What is the reason to depend on compilers here?
> > Wouldn't be a "recommends" relation be sufficient here?
> > An alternative might also be to depend via `:native`, but I did not check that
> You cannot add :native to runtime dependencies. The :native qualifier only
> makes sense for build dependencies. See
> You can find the answer to your question in this thread:
> Essentially, linux-headers-* should depend on gcc-10-for-host:arm64 but that is
> blocked by us not having enough time to work on
Ok, got it. But what about the workaround proposed by Ben Hutchings.
Looks like this fixes the cross compiling, until #666743 is resolved.
IMHO it is also a better workaround than just removing the dependencies as suggested in the mail thread.
> Fixing #666743 would be a major step forward in terms of making packages
> cross-compilable on Debian and derivatives, so if you want to improve the cross-
> building situation in Debian, then this is one of the big open tasks that would
> bring us immensely forward.
> cheers, josch