Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no such thing as a “glibc based alpine image”

ariadne.space

Post reply on HN
Print view View original

31–40 of 204 posts

Re: There is no such thing as a “glibc based alpine image”

#31

Post by tyingq »

ntauthority wrote: post #21
p2t2p wrote: post #16

Earlier 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?

It has certainly evolved to be pretty complicated. You have whatever libc chooses to do with getaddrinfo(), nsswitch.conf, resolv.conf, systemd-resolved, various pieces of software (docker, vpns, wsl), and so on, all trying to control the local resolver.

Re: There is no such thing as a “glibc based alpine image”

#32

Post by akerl_ »

sascha_sl wrote: post #30
akerl_ wrote: post #26

Earlier quoted context omitted.

I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea. But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement. Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpi…

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 suppor…

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.

Re: There is no such thing as a “glibc based alpine image”

#33

Post by account42 »

captainmuon wrote: post #7

A 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 on a really old CentOS and if you are lucky it will work, but I have no trust in this.

As far as glibc or other libraries that take ABI stability seriously go, this does work.

> Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.

Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.

> The dynamic linker doesn't allow you to load two different library versions at the same time (without a lot of contortions). You would think you could do `dlopen` and `dlsym` on two different `.so` files, and then just have separate function pointers to each version's functions. But the linker loves to load all the symbols into a global namespace for some reason.

Having an option to use a separate linking table for specific dlopen calls would be useful, yes.

Re: There is no such thing as a “glibc based alpine image”

#34

Post by captainmuon »

sambe wrote: post #14
captainmuon wrote: post #7

A 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…

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 if I understand correctly.

Re: There is no such thing as a “glibc based alpine image”

#35

Post by ariadneconill »

akerl_ wrote: post #32
sascha_sl wrote: post #30

Earlier quoted context omitted.

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 suppor…

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.

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.

Re: There is no such thing as a “glibc based alpine image”

#36

Post by dijit »

d3nj4l wrote: post #13

I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's causing enough of a support load on them. If it is, I would assume the reasonable solution to that is to close any support requests with "We are not responsible for that image" or something of that variant, or even requesting the creator of the image to menti…

> There's a docker image called alpine-ruby.

There may be, but that seems dangerous. Frankly you can name a dockerhub entry anything you like as long as it's not taken.

But you probably wanted ruby:alpine anyway.

Re: There is no such thing as a “glibc based alpine image”

#37

Post by sascha_sl »

akerl_ wrote: post #32
sascha_sl wrote: post #30

Earlier quoted context omitted.

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 suppor…

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.

It doesn't block it, it requires recompiling musl.

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.

Re: There is no such thing as a “glibc based alpine image”

#38

Post by tyingq »

p2t2p wrote: post #16
Aissen wrote: post #9

Earlier 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…

https://twitter.com/RichFelker/status/994629795551031296

Yikes.

Re: There is no such thing as a “glibc based alpine image”

#39

Post by ariadneconill »

sascha_sl wrote: post #37
akerl_ wrote: post #32

Earlier quoted context omitted.

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.

It doesn't block it, it requires recompiling musl. 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.

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

Re: There is no such thing as a “glibc based alpine image”

#40

Post by akerl_ »

ariadneconill wrote: post #35
akerl_ wrote: post #32

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN