Re: rebootstrap: RISC-V patches
Hi Karsten,
On Wed, Feb 21, 2018 at 10:32:09PM +0100, Karsten Merker wrote:
> https://salsa.debian.org/merker/rebootstrap/tree/riscv-bootstrap-v6
> contains a set of patches against current rebootstrap head that
> improve support for bootstrapping the riscv64 architecture.
> I would apprechiate very much if you could merge them into
> rebootstrap master.
Thank you for the contributions. I see that you split up your work into
four patches:
| RISC-V: use kernel and glibc sources from experimental
| RISC-V: pull build-arch libc6 and host-arch libc6-dev from experimental to avoid build-vs-host version mismatch.
I understand that these things presently require experimental, but I
think that using experimental is not a good trade-off. My experience is
that doing so is fragile (as I learned the hard way with pulling gcc
from experimental). In order for this to work a bit better, you'd need
to use apt pinning.
Encoding the decision of when to use experimental into multiple places
is fragile as well, as they tend to go out of sync. You noticed and
added the second commit.
Finally, it shouldn't be using experimental unconditionally. Once
unstable has a sufficiently recent version, it should stop doing this
and stick with unstable wherever possible.
Thus I think that using linux or glibc from experimental is not worth
the maintenance effort. Simply waiting another month or two will fix
this. You can still keep these patches in your local branch (without
addressing my other concerns) to make progress on other aspects, but I
don't want them. Sorry.
| RISC-V: enable riscv64 in the glibc arch list
There is already code for doing this. Look for where it runs sed on
control.mk. Does it fail for riscv64?
| RISC-V: patch gcc8 to build a single-lib rv64gc-lp64d target for riscv64
This and the previous patch change Debian packages. Thus my patch
inclusion policy requires that you annotate them with your upstreaming
efforts. That can be a Debian bug number, an upstream bug or a commit
id. These need to be in the shell script such that I can quickly
identify when they become droppable and whether progress is being made.
I'm sorry to say that, but it seems like you missed the point of
rebootstrap. Piling up ever more patches onto rebootstrap will only make
it unmaintainable. I have piled up so many patches already that their
maintenance cost has become non-trivial. This year I was able to drop 15
patches and get the script below 5000 lines. I want to get below 3000 by
the end of the year. Don't add to the patch pile, fix things upstream.
You need very convincing reasons to add to the pile and "we are bad at
upstreaming" is a very unconvincing reason at present. In fact it, is so
unconvincing that I never considered avr32 and removed or1k from
jenkins.d.n at some point.
Helmut
Reply to: