6 ms·

It doesn't block it, it requires recompiling musl. https://github.com/docker-library/official-images/pull/10779#issuecomment-906114353 https://github.com/docke

It doesn't block it, it requires recompiling musl. https://github.com/docker-library/official-images/pull/10779#issuecomment-906114353 https://github.com/docker-library/official-images/pull/10779... 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.

ariadneconill 5y ago
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...
- encryptluks2 5y ago
  Can it also get brought up there that you come across as a fascist?
  - ariadneconill 5y ago
    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.
    - encryptluks2 5y ago
      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.
      - ariadneconill 5y ago
        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.
        encryptluks2 5y ago
        > 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.

ariadneconill 5y ago

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

encryptluks2 5y ago
Can it also get brought up there that you come across as a fascist?
- ariadneconill 5y ago
  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.
  - encryptluks2 5y ago
    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.
    - ariadneconill 5y ago
      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.
      - encryptluks2 5y ago
        > 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.