RE: Dependencies of linux-headers-<arch> packages

RE: Dependencies of linux-headers-<arch> packages

[Moessbauer, Felix]

Hi Ben,

> -----Original Message-----
> From: Ben Hutchings <ben@decadent.org.uk>
> Sent: Tuesday, March 8, 2022 1:45 AM
> To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>;
> debian-cross@lists.debian.org
> Cc: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>; Hombourger, Cedric (DI SW
> CAS ES EPT OSS) <cedric.hombourger@siemens.com>; debian-
> kernel@lists.debian.org
> Subject: Re: Dependencies of linux-headers-<arch> packages
> 
> On Thu, 2022-03-03 at 11:13 +0000, Moessbauer, Felix wrote:
> > Hi,
> >
> > the kernel header packages have a dependency to c/c++ compilers.
> > E.g. the "linux-headers-5.10.0-10-arm64" package depends on gcc-
> > 10:arm64 -> cpp-10:arm64 (on bullseye).
> >
> > This becomes an issue when cross-compiling kernel modules for other
> > target architectures:
> > 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?
> 
> We want installation of OOT modules to be as simple as possible for those users
> that need it.  A dependency makes this more robust.
> 
> > Wouldn't be a "recommends" relation be sufficient here?
> > An alternative might also be to depend via `:native`, but I did not
> > check that yet.
> [...]
> 
> Using :native would defeat the purpose.  But the attached patch
> (untested) might fix the dependencies to allow for cross-compilation.

Many thanks for the patch.
I just (manually) backported that to Debian bullseye, tested it for arm64 and it worked like a charm.
Note: In case no compiler is installed yet, the "build" arch (amd64) compiler is preferred which is good.

Having this would be a huge step forward for image builders like ISAR (putting list in CC) targeting embedded devices.
Also regular Debian users that want to compile OOT modules for other architectures (e.g. for the raspberry pi) do not have to fiddle around with a buildchroot anymore.
BTW: It is also a good workaround until #666743 is resolved (multiarch:foreign compiler interface).

Is there a chance we can get this into bullseye? IMHO, the lessened dependency is not a breaking change.

Cheers, Felix

> 
> linux-kbuild does have some support for use in cross-compilation but I don't
> know how well it works now.
> 
> Ben.
> 
> 
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today,
>     ignorance or apathy?
> A.  I don't know and I couldn't care less.

Re: Dependencies of linux-headers-<arch> packages

[Helmut Grohne]

Hi,

On Thu, Mar 10, 2022 at 02:13:34PM +0000, Moessbauer, Felix wrote:
> Many thanks for the patch.
> I just (manually) backported that to Debian bullseye, tested it for arm64 and it worked like a charm.

Can we please stop piling up workarounds and instead fix this once and
for all?

I see us mirroring the "LTS problem" here: Everyone maintains their own
stuff with local patches and it barely works. LTS now has a solution in
the form of freexian where the effort is centralized and made available
for the benefit of everyone.

Helmut

RE: Dependencies of linux-headers-<arch> packages

[Moessbauer, Felix]

Hi Helmut,

> From: Helmut Grohne <helmut@subdivi.de>
> Sent: Friday, March 11, 2022 2:49 PM
> 
> Hi,
> 
> On Thu, Mar 10, 2022 at 02:13:34PM +0000, Moessbauer, Felix wrote:
> > Many thanks for the patch.
> > I just (manually) backported that to Debian bullseye, tested it for arm64 and it
> worked like a charm.
> 
> Can we please stop piling up workarounds and instead fix this once and for all?
> 
> I see us mirroring the "LTS problem" here: Everyone maintains their own stuff
> with local patches and it barely works. LTS now has a solution in the form of
> freexian where the effort is centralized and made available for the benefit of
> everyone.

In general I agree, but here the situation is a bit different:
The dependency to the host compiler (e.g. arm64) is too narrow.
In general, any gcc compiler in the correct version should do.

As discussed earlier the linux-headers -> compiler dependency is just a convenience dep.
I proposed to remove it or move it to the "recommends" section.
But the proposed solution might be better as it maintains backwards compatibility.

For users that just want to cross-compile a module, there is simply no reason why the have to install the compiler for the host architecture (e.g. arm64).
And this use-case is perfectly solved in the patch from Ben.

Felix

> 
> Helmut

Re: Dependencies of linux-headers-<arch> packages

[Helmut Grohne]

Hi Felix,

On Mon, Mar 14, 2022 at 10:33:22AM +0000, Moessbauer, Felix wrote:
> In general I agree, but here the situation is a bit different:
> The dependency to the host compiler (e.g. arm64) is too narrow.

Wrong. It certainly is not and beyond that, this aspect is not weakened.
It still requires a particular version of gcc for the relevant
architecture.

> In general, any gcc compiler in the correct version should do.

Wrong. Ben explained why this is not desired and his patch does not
relax this aspect.

> As discussed earlier the linux-headers -> compiler dependency is just a convenience dep.
> I proposed to remove it or move it to the "recommends" section.

Yes, you proposed that. But it was not an accepted solution and it is
not what Ben's patch does.

> But the proposed solution might be better as it maintains backwards compatibility.

Ben's solution is a workaround. The linux packaging is already complex
in this regard. We need to reduce complexity, not add to it.

> For users that just want to cross-compile a module, there is simply no reason why the have to install the compiler for the host architecture (e.g. arm64).

The essence of cross compilation is a compiler that targets the host
architecture. Of course, you do need it for cross compiling a kernel
module.

> And this use-case is perfectly solved in the patch from Ben.

We seem to be in disagreement of what "perfect" means. Any time, you
iterate over architectures in your dependencies, things are certainly
not perfect as every new architecture will require manual work. Manual
per-architecture work does not qualify as "perfect" to me. While it
solves your use case, it incurs a maintenance cost where a solution with
less cost is available.

Helmut