There is no such thing as a “glibc based alpine image”

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.

Eye roll.

Should glibc reach out as well?

> 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.

  debian-stable
  debian-buster
  debian-slim

  python:3.10-debian
  python:3.10-alpine

So why not:

  glibc-alpine

> they make it clear that it is based off Alpine with the glibc package installed

Well, seeing the number of issues opened on the official Alpine bug tracker regarding this package, it seems it's not that clear.

> if Alpine starts going after people for using alpine in the container image name or tag then I now know what distro to avoid entirely.

Alpine starts going after people for misusing the name and impacting their reputation. This is completely normal and understandable.

Marketing and communication is an important part of every projects, even open source projects, this is not exclusive to businesses. If you want people to support your project, you need to protect your image.

I think the thing that was referred to as a "fork" was the docker image, which uses the package you mention, and afaik is the primary way that people are receiving that package and believing it to be blessed by the Alpine gods. In the sense that the container is a distribution in its own right that deviates from the roadmap of the Alpine makers, it could be considered a fork of sorts. And given that the package naming is far less confusing than the dockerhub naming, I feel like that's what most people on HN are attributing the confusion to.

Note that the article doesn't mention that it's the container that is the source of confusion until the very last section, where it points out what they want to rename. The package itself is called alpine-pkg-glibc and as the author of that package has pointed out, the reason it is called that is to follow alpine package naming conventions, and they have mentioned on this HN convo that they are completely open to changing that name if asked.

But regarding the docker image, I'm well aware that this isn't technically a full fork; I was mirroring the language used on the parent poster - however, since your clarification does not do justice to the complexity of the situation either and implies that you have less clue about what you're talking about, maybe tone it down a bit. Especially since one possible solution to this situation is indeed for the frolvlad/alpine-glibc authors to produce a full fork of Alpine linux with glibc and call it something else (I wonder if Himilayan Linux is available?)