I think the majority of people resort to this hack because security folks in their infinite wisdom require to use alpine and nothing else. Unfortunately, a lot of libraries don't support musl and have no plans to support it in the future, so you have to be creative.
There is no such thing as a “glibc based alpine image”
71–80 of 204 posts
Re: There is no such thing as a “glibc based alpine image”
#72I think this is a perfect example of why the Open Source Definition has "Integrity of The Author's Source Code" If they care about being associated with other people's projects, then they should add a bit to the license that they have to change the name of the project when modifying.
Re: There is no such thing as a “glibc based alpine image”
#73A side-note about glibc: I have only ever had problems with glibc versioned symbols. The only thing they more or less do is to pin an old executable to old library versions, and you can supposedly install a newer version of the library. You then save a little bit of disk space. - It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) - So i…
> It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc. > So if you want a binary to work across multiple distributions, you can build it o…
RTLD_LOCAL?
Re: There is no such thing as a “glibc based alpine image”
#74Earlier quoted context omitted.
Except it's not, as it mixes glibc with musl in ways that induce undefined behaviour you don't expect. If it was recompiling all packages to use glibc, the name would be more appropriate… but also still a trademark violation.
So, of the 49,530 images that show up with several using Alpine somewhere in the name or description... you think this is a trademark violation how? Alpine is synonymous with lightweight images. Several people and vendors use it in their image names.
There is a difference between "python:3.10-alpine" and "alpine-glibc".
One stands for: "we use alpine" (not a trademark violation)
The other one stands for "this is alpine" (a trademark violation)
Re: There is no such thing as a “glibc based alpine image”
#75Earlier quoted context omitted.
> It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc. > So if you want a binary to work across multiple distributions, you can build it o…
RTLD_LOCAL?
Plus also linking with groups, from memory, -Wl,-Bgroup although this may be a Solaris ism.
Re: There is no such thing as a “glibc based alpine image”
#76Earlier quoted context omitted.
I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.
We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…
"For what it's worth, musl's DNS resolver is slated to gain support for TCP responses in the near future" from https://www.linkedin.com/pulse/musl-libc-alpines-greatest-we...
Re: There is no such thing as a “glibc based alpine image”
#77Earlier quoted context omitted.
Would you not just have more subtle, harder to debug problems if it were not for versioned symbols?
I'm not at all against versioning , but found glibc's implementation a source of frustration. It would be great if you could install Qt 5.9, 5.12, 1.14 in parallel and have apps use the latest version (except for that one app that triggers a bug where you fix it to 5.9). This is an actual problem that occurred at work, I had to statically compile Qt in that case. Glibc's idea of lib versions doesn't help here at all…
That’s not so much glibc’s fault, but the Unix philosophy of /lib, right? Windows’ “solution” to this is to basically require applications to provide their own runtime (such as Qt, GTK, etc.).
Re: There is no such thing as a “glibc based alpine image”
#78Earlier quoted context omitted.
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 possibl…
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…
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.
Re: There is no such thing as a “glibc based alpine image”
#79Earlier quoted context omitted.
We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…
Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?
libc provides the standard POSIX sockets APIs, which include DNS functions such as gethostbyname() and getaddrinfo()
Re: There is no such thing as a “glibc based alpine image”
#80Earlier quoted context omitted.
Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?
It probably made sense in 1983. https://github.com/dank101/4.2BSD/blob/master/include/netdb....
I think back then libresolv was separate from libc since many programs didn’t need it, and memory was tight