> On 2 Dec 2022, at 05:11, Andrey Grozin <gro...@woodpecker.gentoo.org> wrote:
>
> Hello *,
>
> The sbcl upstream only supports glibc Linux systems. Building sbcl uses sbcl
> binary (which fails to run on musl) to compile sbcl sources.
>
> In principle, one can try a workaround: use some other lisp (say, clisp or
> ecl) as the bootstrap lisp. This way is at best brittle: there is no
> guarantee that these external lisps will compile the sbcl sources
> successfully. People say that sometimes this works.
>
> No user of musl profiles could successfully emerge sbcl from time -infinity
> to the present moment. The natural solution is to pmask sbcl in musl profiles.
>
> So I've done. But this leads to unexpected consequences. dev-ros/roslisp hard
> depends on sbcl. ros-meta/ros_core hard depends on roslisp. ros-meta/ros_base
> hard depends on ros_core. ros-meta/{perception,robot,viz} hard depend on
> ros_core. Maybe, more packages depend on {perception,robot,viz}, I haven't
> checked.
>
> This means that no user of the musl profiles has ever been able to emerge all
> these packages (because they did not have sbcl). And all these packages
> should be pmasked in the musl profiles.
>
> Before doing this drastic change I decided to ask for your advice. Should I
> go forward and pmask them now? Or maybe for some of them the dependence on
> sbcl can be made optional, and it would be sufficient to use.mask such an
> option name? Or maybe roslisp can use some other lisp instead of sbcl?
> Thanks for asking and for looking to sort it out for musl. If the dependencies are optional (at least for some), we should indeed (package.)use.mask sbcl on musl to reduce the damage, then package.mask the remaining unconditional reverse dependencies. For things like this, I tend to use GitHub pull requests because you get CI for free to see if the masks are sufficient, and if not, what the problems are. But you can emulate that using pkgcheck scan on the whole tree locally. Best, sam
signature.asc
Description: Message signed with OpenPGP
