Package: musl-dev,libcrypt1-dev Severity: important User: helm...@debian.org Usertags: rebootstrap
Both musl-dev and libcrypt1-dev contain crypt.h. I acknowledge that this does not cause a file conflict, because musl's lives on a multiarch path, but we have two conflicting headers in the search path and what happens from there is pretty much undefined. It also happens that musl ships an empty libcrypt.a as the main libc object includes all the functions. So linking both musl and libxcrypt's libcrypt would be broken as well. Quite obviously, there should be one and only one provider of this functionality. I see two options: 1. Retain status quo Before the introduction of libxcrypt, musl was providing these functions and continues to do so. libxcrypt should simply not build for musl-linux-any architectures. Thus libxcrypt would become a glibc-only thingy. Doing so is straight forward. You simply change the architecture fields of binary packages from "any" to "gnu-any-any". That means that libxcrypt only becomes a thing for glibc architectures. 2. Move crypt functionality to libxcrypt musl should stop building and including libcrypt and crypt.h functionality. It seems that musl upstream is not prepared for doing this. Work is needed on the musl side for doing this. I don't immediately see which of these options is "better". Both of them have advantages and disadvantages. For instances, the first option means more differences between musl and glibc, which tends to make porting harder. On the other hand, the first option is vastly simpler to implement. Likely, this question should be discussed with upstreams as well. I defer this question to the respective maintainers and simply report the problem here. Please coordinate a solution and reassign the bug as appropriate. Helmut
