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

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.