Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Control: tags -1 + wontfix Control: close -1 Thanks for all your inputs! signature.asc Description: PGP signature
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Helmut Grohne dixit: >be dropping those dependencies. If you do that in a profile, the >contents of the mksh package vary with the profile. However, if you The contents vary anyway. If a libc is not available (ok, this does not happen with normal Debian Build-Depends) or produces a faulty executable, it’s skipped. (And yes, this is by design.) >split mksh-static to a separate package, you only change the package mksh-static is just a symlink to the “best” one, but I ship all ones. >point, I'm aiming for three categories: Low hanging fruit, tooling bugs >and packages must be cross buildable for some reason. The bug at hand OK, works for me. >That may be correct, but I still fail to see why I would want a compact Yes, which is why I’m not going there, it’s off-topic, I have reasons and not the nerve to explain to someone who fails to see it. There are other factors in play as well. >I still wonder what do do about the bug now. We've figured that no, Nothing. >So how bad would it be to close this bug with the wontfix tag? Or leave it open with it. I don’t care. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Hi Thorsten, On Tue, May 12, 2020 at 10:19:52PM +, Thorsten Glaser wrote: > >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. I somehow missed writing down essential parts of the thought process. As you figured out, getting the musl-gcc or diet wrappers to work with cross compilation is practically impossible, so the only route seems to be dropping those dependencies. If you do that in a profile, the contents of the mksh package vary with the profile. However, if you split mksh-static to a separate package, you only change the package set. Your profile would likely be "pkg.mksh.nostatic". Then one could cross build mksh with that profile. > 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. I do try to make much of the archive cross buildable, yes. But at this point, I'm aiming for three categories: Low hanging fruit, tooling bugs and packages must be cross buildable for some reason. The bug at hand fits in the tooling category, but unfortunately it is not very easy to resolve as it would likely block on #666743 (like so many things). > 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.) That may be correct, but I still fail to see why I would want a compact mksh in the first place. The dynamically linked one seems reasonably small and the savings to klibc seem irrelevant at a global scale. It seems like your approach actually makes the mksh package larger by providing four copies of the same thing. I still wonder what do do about the bug now. We've figured that no, fixing it is not that simple. So what if we really were after fixing it (without implying that it is worth the trouble)? musl-tools would have to be split into even smaller packages. As Reiner pointed out, at least the .specs file is certainly not M-A:foreign. Instead, it should live in some coinstallable package. musl-gcc is fully architecture-dependent and rightly so. The fix for that is prefixing it with the host architecture: x86_64-linux-musl-gcc. So we could split out a gcc-x86-64-linux-musl package that contains x86_64-linux-musl-gcc and the spec file and mark it Multi-Arch: foreign (because the architecture being operated on is part of the name). Then musl-tools could depend on that and ship a musl-gcc symlink. Unfortunately, that'll cause pain with #666743 down the road as gcc-defaults should eventually provide the very same package for the same architectures. It would be a temporary solution. So how bad would it be to close this bug with the wontfix tag? Helmut
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
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
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Hi Thorsten, On Mon, Mar 16, 2020 at 10:49:29PM +, Thorsten Glaser wrote: > Back to the original place where I saw this: so how do we make mksh > cross-buildable/-bootstrappable? I think moving mksh-static to a separate binary package would be pretty much required for making it cross buildable. Do you have a practical need for it to be cross buildable? > For bootstrapping, we can remove the extra libcs, it will work with > just glibc, although the package content will differ. Is there a > standard build profile for that already, and which releases support > that? debian/rules and everything it calls already handle absence > of dietlibc, klibc, musl fine. The build profile syntax is mostly recognized since jessie if I remember correctly. So that should be pretty much compatible with all you want to backport to. > Question is also, should we even invest into making those libcs > usable in a cross context? I actually think we should, but a little different than you may imagine. Why do you want a different libc in the first place? What does musl give you that glibc doesn't? Maybe you say "musl is smaller". While that is true, you only gain from that benefit if you actually remove glibc from 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 architecture triplet (e.g. x86_64-linux-GNU), using a different libc requires a different architecture in my view. In other words: Yes, by all means, make your package work for architectures like musl-linux-any, but stay away from musl on a glibc architecture. It's a pain like multilib. If you want mksh linked with musl, add a musl architecture and install it from there. Helmut
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Johannes Schauer dixit: >with /usr/lib/x86_64-linux-musl/musl-gcc.specs as a spec file. Both of these >things make the interface provided by the package musl-tools architecture >dependent. This means that a package that musl-tools:amd64 will give you >different functionality compared to musl-tools:i386. I had thought it would compile to the target architecture then. But perhaps it is too dangerous. Back to the original place where I saw this: so how do we make mksh cross-buildable/-bootstrappable? Ideally, the full set of dependencies as necessary would be there. For bootstrapping, we can remove the extra libcs, it will work with just glibc, although the package content will differ. Is there a standard build profile for that already, and which releases support that? debian/rules and everything it calls already handle absence of dietlibc, klibc, musl fine. Question is also, should we even invest into making those libcs usable in a cross context? bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Hi Thorsten & Reiner, Quoting Thorsten Glaser (2020-03-14 18:26:24) > >Enabling M-A:foreign for musl-tools is unfortunately currently not > >possible. It's not arch:all, as it ships a few arch-dependent files. > > That’s true for other packages as well. > > A package can, generally, be made Multi-Arch: foreign, if it, and > all of its dependencies, can be used on a foreign system which has > the capability to execute its code (e.g. i386 on an amd64 system, > or anything with qemu-user-static). you are right. Even arch:any packages are allowed to have a m-a:foreign annotation. Unfortunately, there are more conditions than the one you name before it is correct to mark a given package as m-a:foreign. > >E.g. the spec file, /usr/bin/musl-gcc (which hardcodes the arch-dependent > >path to the spec file), and /usr/bin/musl-ldd, which is a symlink to > >libc.so. > > Yes, but that’d be deliberate. Installing a foreign-architecture > musl-tools would then enable one to cross-compile. At least that’s > the idea. I’m not completely sure it’s the right way or even a good > way, or whether it’ll break $things, which is why I added the two “cross” > guys in Cc. I only had a very quick look at what musl-tools does but I do not think that it is correct to mark it as m-a:foreign. /usr/bin/musl-ldd is a direct symlink to /lib/x86_64-linux-musl/libc.so and /usr/bin/musl-gcc just calls /usr/bin/cc with /usr/lib/x86_64-linux-musl/musl-gcc.specs as a spec file. Both of these things make the interface provided by the package musl-tools architecture dependent. This means that a package that musl-tools:amd64 will give you different functionality compared to musl-tools:i386. For more context, read this handy write-up by Helmut: https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign Thanks! cheers, josch signature.asc Description: signature
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Reiner Herrmann dixit:
>Enabling M-A:foreign for musl-tools is unfortunately currently not
>possible. It's not arch:all, as it ships a few arch-dependent files.
That’s true for other packages as well.
A package can, generally, be made Multi-Arch: foreign, if it, and
all of its dependencies, can be used on a foreign system which has
the capability to execute its code (e.g. i386 on an amd64 system,
or anything with qemu-user-static).
>E.g. the spec file, /usr/bin/musl-gcc (which hardcodes the arch-dependent
>path to the spec file), and /usr/bin/musl-ldd, which is a symlink to
>libc.so.
Yes, but that’d be deliberate. Installing a foreign-architecture
musl-tools would then enable one to cross-compile. At least that’s
the idea. I’m not completely sure it’s the right way or even a good
way, or whether it’ll break $things, which is why I added the two
“cross” guys in Cc.
bye,
//mirabilos
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Hi Thorsten, On Sat, Mar 14, 2020 at 03:52:01AM +0100, Thorsten Glaser wrote: > I just discovered https://bootstrap.debian.net/cross_all/mksh.html > seems to be hung up on musl-tools wanting the native compiler. > > Wondering whether, if musl-tools were M-A:foreign, it could satisfy > cross-compiling dependencies? > > Perhaps, even if not (and we’d need something else) M-A:foreign > won’t hurt? (Cosidering the i386/amd64 case for example.) Enabling M-A:foreign for musl-tools is unfortunately currently not possible. It's not arch:all, as it ships a few arch-dependent files. E.g. the spec file, /usr/bin/musl-gcc (which hardcodes the arch-dependent path to the spec file), and /usr/bin/musl-ldd, which is a symlink to libc.so. So unfortunately I currently have no solution to your problem. Kind regards, Reiner signature.asc Description: PGP signature
Bug#953853: musl-tools: should it be Multi-Arch: foreign?
Package: musl-tools Version: 1.1.24-1 Severity: wishlist I just discovered https://bootstrap.debian.net/cross_all/mksh.html seems to be hung up on musl-tools wanting the native compiler. Wondering whether, if musl-tools were M-A:foreign, it could satisfy cross-compiling dependencies? Perhaps, even if not (and we’d need something else) M-A:foreign won’t hurt? (Cosidering the i386/amd64 case for example.) -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages musl-tools depends on: ii gcc 4:9.2.1-3.1 ii musl-dev 1.1.24-1 musl-tools recommends no packages. musl-tools suggests no packages. -- no debconf information
