These are completely different situations. Wanting glibc compat on Alpine is not an unusual requirement, unlike your "alpine-goofy" image, and the bugs it introduces are subtle and may not show up at all in some use-cases.
Believe it or not, a lot of developers aren't aware we have different libc implementations at all, the "exec format error" or "file not found" errors alpine spits out already create a lot of support burden.
the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system.
it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.
It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibly be inaccurate.
I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system.
Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems?
If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later.
Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.
As visible upthread, I think starting w/ the block in code is a bad move, and am sad that reaching out to the maintainer of alpine-glibc seems like an afterthought.
That said, there is not a universal mandate for how an open source project “must behave”, other than that the terms of the license (which the authors of the code are able to choose). There isn’t a single cohesive “entire fucking point” of open source. The things proposed in the blog post are permissible under the license, are able to be bypassed by the user, and are not some earthshattering affront to human decency.
We should be able to disagree about the best course of action without falling into incendiary accusations.
> You don't get to tell your users how to use your project.
Sure I guess but "don't footgun yourself" is pretty different. But I guess some people just like using linux for the novelty of breaking shit and feeling smart about fixing it.
This is also a response to inclusion of this broken mess into official docker images, I think alpine putting their foot down is entirely justified here.
correct: we do not want to get stuck with having to deal with angry people who have unstable environments caused by this.
and, the conflict option is one of a few options being considered. part of what lead up to this is the fact that we have not taken any public position on mixing glibc and musl runtimes until now.
no decision has been made, and won't be made until the TSC meeting next week...
I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
When your first reaction in all this was to figure out a way to try to block a third-party package from being installed, and then you make comments like... "we feel it appropriate to signal our position more
forcefully." And then you lock comments on GitLab from people commenting..
You could have, before even writing the blog post, posted an issue on their GitHub to try seeing if they can post a more noticeable disclaimer... although it doesn't really even need one and is pretty inherent, just like all the other Docker Hub images using Alpine in their name to indicate the underlying distro.
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You also assume that this is our first reaction.
Our first reaction was 6 years ago when it first came out: meh.
No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
It is unfortunate that we have waited this long to put our foot down, honestly!
We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Stop assuming this is our "first" reaction. It isn't. I even said it wasn't to begin with -- a "first" reaction cannot logically be an escalation from a previous position, it must be an initial one.
> The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
> The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
You were specifically trying to block the package from being installed without recompiling musl.
> This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You're putting too much pressure on yourself. This is simple... if someone isn't using the official Alpine image (alpine) then they should ask for support from the image creator, as there are thousands of things that can go wrong outside of you control.
> No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
Labeling other developers work as hackjob images is condescending. Your whole post was condescending. Just because someone has alpine in an image tag doesn't mean that they are trying to indicate that it uses stock Alpine as the base image, but instead that it uses Alpine as the underlying distro. Who knows what software or changes they've added to it that may cause issues outside of Alpine's control.
> It is unfortunate that we have waited this long to put our foot down, honestly!
> We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
> The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Seriously, these comments only show that this is more about control for you than anything. I can't say for sure, but I have a feeling that eventually other people in the community will either leave or ask you to leave for toxic behavior like this.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes.
You ignore the point I am making: people are already fighting this issue for years, and Alpine has not taken a position on it until now.
We should have done so sooner, but unfortunately we did not, so a more theatric approach is sometimes needed to make a point.
We want to discourage bad practices in the creation of alpine-based images, so that our partners (such as the Docker library team) do not have to deal with user complaints with images, or feel like companies are bullying them into accepting images they know are built with bad practices.
If you call taking action to provide assistance requested by our ecosystem partners (who have been thrilled that we are putting our foot down by the way) toxic behavior I wouldn’t want to know what your idea of a party is to be blunt.
It does when it's causing excessive load on upstream from users who think what is effectively an outright broken configuration is supported.
Preventing footguns and providing users the ability to continue using it if they really really want to seems like a sane option?
Believe it or not, a lot of developers aren't aware we have different libc implementations at all, the "exec format error" or "file not found" errors alpine spits out already create a lot of support burden.