Helmut Grohne dixit: >I think moving mksh-static to a separate binary package would be pretty >much required for making it cross buildable.
I completely do not follow. Anything you’d want to do in a separate binary package could be done in the same binary package. >Do you have a practical need for it to be cross buildable? No, not really, just found this in some Debian QA tool and wondered about it; the inability to cross-build with musl seems to be the only blocker. If not being able to cross-build mksh with musl isn’t a problem for Debian, I don’t think investing more time into it is worth it. >all you want to backport to. Hah hah hah… but I have branches anyway. >Why do you want a different libc in the first place? What does musl give Things, but that’s off-topic, and I’m not going there. >your system. So I think the way to support musl and other libs is not >the current "we package another libc under a glibc architecture", but >properly porting Debian to another libc. Since the libc is part of the That works for musl, which is a full, correct environment, but not so much for dietlibc and especially klibc (which, for example, deliberately doesn’t support using the FPU). mksh builds against all four, if found, and then chooses the “best” one for /bin/mksh-static and lksh. (This currently ends up being klibc on all systems with musl, even though musl is more correct, since we’re aiming for compactness here.) I’m taking from this discussion: let’s just not do anything. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
