main/musl: add conflict against glibc

There is a third-party package which installs glibc in an allegedly compatible way with musl. It is our opinion that while this package can co-exist with musl, the end result of running binary blobs that combine libraries expecting musl libc with glibc code, without a proper emulation layer like gcompat, results in undefined behavior.

Accordingly, we are unwilling to provide support for this configuration. This has been our historic position on the alpine-pkg-glibc project since its inception, however, due to increased attention and attempts to use it in production, we feel it appropriate to signal our position more forcefully.

Fixes: https://github.com/docker-library/official-images/pull/10779

cc @fabled @team/TSC

mentioned in issue tsc#17

I am against this. There are no real technical hard conflict with glibc+musl. It absolutely is a bad idea to mix those but I don't think we should go this far to prevent users from shooting themselves in the foot.

locked this merge request

We (the TSC) will take actions to discourage (and preferably educate) users on avoiding patterns and advice that results in unstable or unsupportable configurations. This is not even unusual for a distribution to do, for example Debian has an entire set of wiki pages about avoiding patterns that result in a broken system.

Anyway, this is one of multiple options that the TSC is considering about this specific issue. Combining glibc and musl runtimes is basically all but guaranteed to create an unstable environment, unless the system is appropriately configured (glibc side uses glibc binaries only, and vice versa).

This MR does not stop somebody from installing glibc if they really want it, it simply forces them to rebuild the musl package with ALLOW_GLIBC_PKG=1 enabled.

At any rate, I am locking this MR to TSC members only, since frankly, nobody here is interested in drive-by commentary.

I feel that the end users should have clear in their mind that this package is not officially supported by Alpine. Perhaps a disclaimer in the pre-install script, a README in the package and in the web page distributing this package should suffice. This could be suggested to the alpine-glibc maintainers. But I'm not sure this is something we can force.

After all, I believe that anything not signed with the Alpine signing keys and downloaded from outside alpinelinux.org domain proves that is not officially supported by Alpine and you cannot expect any support nor file a complaint or a lawsuit for breaking your environment.

In IRC, @ncopa and @clandmeter pointed out there are other ways to create so-called 'franken-alpines' without even leaving Alpine's repositories, such as mixing packages across branches.

We probably want to make it clear that creating these scenarios is also unwise. So I can be swayed that a technical approach of encoding a conflict against glibc in musl's packaging may be less effective than handling this as a documentation issue.

But we should discuss this at the next TSC meeting regardless, so we can at least determine how to approach it if we choose to handle this as a documentation issue.

The consensus amongst TSC members seems to lean towards not taking a technical action to block this, but instead formally documenting bad practices that are likely to result in breakage. Let's defer to tsc#17 and use it as a workspace for identifying the types of configurations we wish to discourage in this document.

I'm going to unlock the MR for now, but it will be closed in favor of tsc#17.

closed

unlocked this merge request

mentioned in issue #6375 (closed)