6 ms·

These are completely different situations. Wanting glibc compat on Alpine is not an unusual requirement, unlike your "alpine-goofy" image, and the bugs it intro

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.

akerl_ 5y ago
The fact that a downstream image is popular doesn’t make it sane for upstream to want to literally block its existence via code changes.
- ariadneconill 5y ago
  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.
  - akerl_ 5y ago
    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.
    - ariadneconill 5y ago
      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.
      - MrStonedOne 5y ago
        alpine exists in the open source space and must behave like an open source project. You don't get to tell your users how to use your project. That is the entire fucking point of open source software.
        akerl_ 5y ago
        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.
        puffyvolvo 5y ago
        > 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.
        ariadneconill 5y ago
        I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.
      - yjftsjthsd-h 5y ago
        The user already had to go out of their way to install it; I'm not sure adding an extra flag is a huge difference.
- sascha_sl 5y ago
  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.
- puffyvolvo 5y ago
  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?

akerl_ 5y ago

The fact that a downstream image is popular doesn’t make it sane for upstream to want to literally block its existence via code changes.

ariadneconill 5y ago
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.
- akerl_ 5y ago
  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.
  - ariadneconill 5y ago
    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.
    - MrStonedOne 5y ago
      alpine exists in the open source space and must behave like an open source project. You don't get to tell your users how to use your project. That is the entire fucking point of open source software.
      - akerl_ 5y ago
        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.
      - puffyvolvo 5y ago
        > 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.
      - ariadneconill 5y ago
        I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.
    - yjftsjthsd-h 5y ago
      The user already had to go out of their way to install it; I'm not sure adding an extra flag is a huge difference.
sascha_sl 5y ago
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.
puffyvolvo 5y ago
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?