Bug#1065416: Bastian's offer in #1065416

On 12.09.24 19:56, Ben Hutchings wrote:
> On Thu, 2024-09-12 at 12:19 +0200, Helmut Grohne wrote:
>> Hi Ben,
>>
>> Dropping leader@ and community@ from Cc as this is a technical
>> side-track.
>>
>> On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:
>>> On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
>>> [...]
>>>> My answers below are mine alone.  I have not discussed this with other
>>>> team members and do not speak for them.
>>>>
>>>> On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
>>>>> Hello kernel maintainers,
>>>>>
>>>>> While potential solutions to this bug are being discussed, would you
>>>>> please consider removing the Provides from linux-libc-dev?
>>>>
>>>> I am open to doing so.
>>> [...]
>>>
>>> I raised this at today's team meeting and it was agreed to do this; see
>>> <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1198>.
>>
>> Thank you.
>>
>> I note that these provides (while causing problems) also solved one
>> problem that now reappears. linux-libc-dev is marked `Multi-Arch:
>> foreign`, but this technically is a lie. It does not provide
>> linux-libc-dev for all architectures - not even for all linux-any
>> architectures and never will.
> [...]
> 
> It is trivial for us to add support for additional architectures once
> they are minimally supported in upstream Linux (we may also require
> that dpkg recognises their triplet; I'm not sure).  There is no
> requirement that we define a kernel configuration for the architecture
> at the same time, or ever (see x32).
> 
> Can we assume that new Debian Linux ports will be able to satisfy that
> or would that be a problem sometimes?

CCing Adrian, he recently wanted to provide cross toolchains for 
sparc-linux-gnu and ia64-linux-gnu, which the kernel doesn't provide 
anymore. So a design which allows these toolchains would be helpful.