Hi,
I skipped replying here earlier, because I felt like I would not add any
content. Stefano indicated that my impression was wrong. Hence replying
now.
On Thu, Oct 24, 2024 at 01:31:32AM +0200, Ben Hutchings wrote:
> On Sat, 2024-10-19 at 18:15 +0200, Helmut Grohne wrote:
> > Hi Bastian,
> >
> > On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote:
> [...]
> >
> > > But now you can have a port without hand patched linux that is built in
> > > a non-standard way and relying on internal and unstable package API,
> > > just be talking and getting it added to the package first.
> >
> > Fair enough. Please add arc, cksy, mipsr6el, sh3, sparc, and
> > musl-linux-any. Thanks in advance.
In retrospect, the use of irony was not the best of moves here as it did
not add clarity to a discussion that was already heated. I'm sorry about
that.
> We would need to know the multiarch triplet for csky.
Yes, exactly. Let me reiterate the reasons for why I prefer a different
solution here.
* In general terms, the multiarch triplet is something that
can change (and has changed) during the early phase of an
architecture bootstrap.
* When an architecture becomes available in toolchain packages, it is
not clear whether it takes off. or1k very much looked like the next
thing and now it is deleted. The story for tilegx is similar.
Initially, riscv64 looked a lot like or1k. In not adding these to
src:linux (and removing them later), we avoid a pile of unnecessary
interaction. The excessive addition of architectures also interacts
with #1081826.
* It is very useful to locally add a new architecture and try a
bootstrap to give feedback to upstreams as to what piece is missing.
Not requiring src:linux to cooperate significantly speeds up this
evaluation process.
I generally see src:linux as one of the later pieces relevant to
architecture cross bootstrap in the sense that while it is one of the
earliest packages needed for its headers, adding real support is often
delayed, because too many out-of-tree patches are required during the
initial bootstrap phase and thus everyone uses a self-built vendor
kernel there.
Automatically modifying src:linux is quite feasible. It has changed a
couple of times and now roughly looks like this:
cat >debian/config.local/defines.toml >/dev/null <<EOF
[[kernelarch]]
name = '$kernel_arch'
[[kernelarch.debianarch]]
name = '$deb_arch'
EOF
./debian/rules debian/rules.gen
This is quite mechanical and therein lies value. The difficulty now has
become that src:linux is the only package in the entire architecture
cross bootstrap that builds an architecture-dependent Arch:all package.
I have not yet found a good way to deal with this oxymoron.
Helmut
