Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod
From: Stefano Rivera <stefanor@debian.org>
Newsgroups: linux.debian.bugs.dist,linux.debian.kernel
Subject: Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap
Date: Tue, 04 Mar 2025 18:00:02 +0100
Message-ID: <KmDMC-3AFS-15@gated-at.bofh.it>
References: <JQiQ9-dUCh-9@gated-at.bofh.it> <JQlbj-dVTg-5@gated-at.bofh.it> <Jw7ND-HVS-1@gated-at.bofh.it> <JQrA5-e04Z-27@gated-at.bofh.it> <Jw7ND-HVS-1@gated-at.bofh.it> <K9GRX-cuj0-3@gated-at.bofh.it> <Jw7ND-HVS-1@gated-at.bofh.it> <KcrMJ-elGf-3@gated-at.bofh.it> <Jw7ND-HVS-1@gated-at.bofh.it> <KcuUh-enFc-1@gated-at.bofh.it> <Jw7ND-HVS-1@gated-at.bofh.it> <KcuUh-enFc-1@gated-at.bofh.it>
X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org  Tue Mar  4 16:51:10 2025
Old-Return-Path: <debbugs@buxtehude.debian.org>
X-Spam-Flag: NO
X-Spam-Score: -4
Reply-To: Stefano Rivera <stefanor@debian.org>, 1084908@bugs.debian.org
Resent-To: debian-bugs-dist@lists.debian.org
Resent-Cc: Debian Kernel Team <debian-kernel@lists.debian.org>
X-Debian-Pr-Message: followup 1084908
X-Debian-Pr-Package: linux-libc-dev
X-Debian-Pr-Source: linux, linux-2.6, linux-2.6.24
X-Gpg-Public-Key: https://www.rivera.za.net/stefano.gpg
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
User-Agent: NeoMutt/20250113
X-Debian-Message: from BTS
X-Mailing-List: <debian-bugs-dist@lists.debian.org> archive/latest/1890963
List-ID: <debian-bugs-dist.lists.debian.org>
List-URL: <https://lists.debian.org/debian-bugs-dist/>
Approved: robomod@news.nic.it
Lines: 46
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
X-Original-Cc: Bastian Blank <waldi@debian.org>, Matthias Klose <doko@debian.org>
X-Original-Date: Tue, 4 Mar 2025 12:47:37 -0400
X-Original-Message-ID: <wzxaa5qwu7ourwg2iivaufhy3u6fwm5oqzlx3uyimeaa4vrusk@fijix7fwndhs>
X-Original-References: <20241205073835.GB220964@subdivi.de> <20241205143053.r5ro5mv5ofghmo2z@shell.thinkmo.de> <20241010160324.GA2302216@subdivi.de> <20241205203354.GA971206@subdivi.de> <20241010160324.GA2302216@subdivi.de> <6e4a64c4wu5eokwixxk7exonchjf3meptzx2b3nspjjipllhie@rbrsp6kpviti> <20241010160324.GA2302216@subdivi.de> <20250204140507.47xkhx4xqfi35brl@shell.thinkmo.de> <20241010160324.GA2302216@subdivi.de> <20250204172508.n5zih5molgahfkph@satie.tumbleweed.org.za> <20241010160324.GA2302216@subdivi.de> <20250204172508.n5zih5molgahfkph@satie.tumbleweed.org.za>
Xref: csiph.com linux.debian.bugs.dist:1236118 linux.debian.kernel:86334

Hi Bastian (2025.02.04_13:25:08_-0400)
>The resolution of the issue brought to the tech-ctte requires figuring
>out whether linux-libc-dev will take over providing these headers for
>cross toolchain building, or whether cross-toolchain-base continues to
>own the linux-libc-dev-${arch}-cross virtual package names (and provides
>symlinks or duplicates of headers).

I've had a few IRC conversations with both Bastian and Matthias about 
what comes next. No conclusions yet, but the ground we've covered is:

Matthias is asserting that the -cross package namespace and 
/usr/<triplet> sysroot directories belong to cross-toolchain-base. He'd 
like to keep control of those packages.

Bastian is concerned that if both linux-libc-dev and 
linux-libc-dev-*-cross provide linux headers in different paths they 
should conflict with each other to avoid compilers accidentally sourcing 
the wrong headers. linux-libc-dev installs in the usual multiarch 
include directory (/usr/include/$ARCH/linux/). linux-libc-dev-*-cross 
installs in the sysroot directory (/usr/$ARCH/include/linux/)

I would imagine that any conflicts like that would make 
linux-libc-dev-*-cross practically uninstallable in any situation where 
you'd need them (libc6-dev depends on linux-libc-dev).

So, we're back to trying to unpick this knot. The Techncial Committee is 
not supposed to do design work, but I can see some possible ways out of 
this.

I could see a scenario where linux-libc-dev-*-cross are tiny wrapper 
packages, depending on linux-libc-dev and including symlinks from one 
include directory to the other. I assume that wouldn't need the 
Conflicts?

Or if the Conflicts were more version-targetted and allow linux-libc-dev 
and linux-libc-dev-*-cross to co-install if they were built from the 
same linux source version, would that be acceptable?

Do either of you have any thoughts on how we should figure this out?

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272