4 ms·

Thanks for your "clarification", however I don't think you've fully grokked the situation yourself. I think the thing that was referred to as a "fork" was the

Thanks for your "clarification", however I don't think you've fully grokked the situation yourself. 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?)

encryptluks2 5y ago
So, let's say I create a Docker Hub image with alpine as the base, then I install a package from the Alpine repo.. let's say Chromium. So now you're telling me, that is a fork of Alpine and I should be forced to recompile Alpine entirely anytime I want to install a package and create a Docker Hub image? I guess that is one way to ensure no one uses Alpine for container images ever again.
- undecisive 5y ago
  I'll be boring and ignore the straw man if you don't mind, and continue to focus on the theme of "people here are commenting without having any clue as to what they are talking about" > then I install a package from the Alpine repo You might want to do some research - from the readme: "The current installation method for these packages is to pull them in using wget or curl and install the local file with apk" - https://github.com/jeanblanchard/docker-alpine-glibc/blob/master/Dockerfile https://github.com/jeanblanchard/docker-alpine-glibc/blob/ma... <- That dockerfile, for example, installs curl using the normal Alpine repos, then uses curl to download the signing keys and the packages for the glibc package. But yes, if someone builds a chrome package that completely screws up other packages in alpine, to the point that the Alpine maintainers are being inundated with bogus support requests then yes, ONE SOLUTION is to recompile the project in a way that means that the package is no longer a problem. You have solved the problem with a fork. The other solution is to make it very very clear in your naming and documentation that this is not a supported alpine image, and that bug reports should go to the maintainer of the image, not Alpine themselves. However, either way, you could be argued to have created a new "distribution" of software that is no longer truly Alpine linux, but is based on Alpine linux. Including Alpine in the name is not necessary, and in this case it seems, not desirable. Even if your codebase is not a fork, you have "forked off" from the original distribution.

encryptluks2 5y ago

So, let's say I create a Docker Hub image with alpine as the base, then I install a package from the Alpine repo.. let's say Chromium. So now you're telling me, that is a fork of Alpine and I should be forced to recompile Alpine entirely anytime I want to install a package and create a Docker Hub image? I guess that is one way to ensure no one uses Alpine for container images ever again.

undecisive 5y ago
I'll be boring and ignore the straw man if you don't mind, and continue to focus on the theme of "people here are commenting without having any clue as to what they are talking about" > then I install a package from the Alpine repo You might want to do some research - from the readme: "The current installation method for these packages is to pull them in using wget or curl and install the local file with apk" - https://github.com/jeanblanchard/docker-alpine-glibc/blob/master/Dockerfile https://github.com/jeanblanchard/docker-alpine-glibc/blob/ma... <- That dockerfile, for example, installs curl using the normal Alpine repos, then uses curl to download the signing keys and the packages for the glibc package. But yes, if someone builds a chrome package that completely screws up other packages in alpine, to the point that the Alpine maintainers are being inundated with bogus support requests then yes, ONE SOLUTION is to recompile the project in a way that means that the package is no longer a problem. You have solved the problem with a fork. The other solution is to make it very very clear in your naming and documentation that this is not a supported alpine image, and that bug reports should go to the maintainer of the image, not Alpine themselves. However, either way, you could be argued to have created a new "distribution" of software that is no longer truly Alpine linux, but is based on Alpine linux. Including Alpine in the name is not necessary, and in this case it seems, not desirable. Even if your codebase is not a fork, you have "forked off" from the original distribution.