Hello guys,
While I'm an old Gentoo user, there is a question I was never able to answer in a proper way.
I install X package that requires Y language for its compilation. Once the compilation is done, do I need Y language installed? I mean, it's a hard dependency for X package, so: how to deal with that kind of dependencies?
Of course, this question doesn't take into account interpreted languages like python or perl but yet, I find a bit odd to need ~600MB of Go just because I have Docker installed.
Thanks in advance.
Go relevance after Docker is installed
Message
If the requirement is only for build-time, then no, you don't need it installed. The ebuild, if properly written, already handles this by specifying Y in DEPEND and not in RDEPEND. If you later use emerge --depclean --with-bdeps=n --ask --verbose dev-lang/go, you should be allowed to remove Go. Note that it will be needed again if you ever build an upgrade.
Yes, it's pretty silly to need 600MB of an otherwise unused language just to compile some source files, and then not need it again to use the compiled program. However, Go isn't as unused as it appears. Part of what makes this look strange is that Docker does depend on Go at runtime, but doesn't depend on dev-lang/go, because Go is very bad about static linking things, so all the Go bits that Docker needs were linked right into the installed Docker files.
Yes, it's pretty silly to need 600MB of an otherwise unused language just to compile some source files, and then not need it again to use the compiled program. However, Go isn't as unused as it appears. Part of what makes this look strange is that Docker does depend on Go at runtime, but doesn't depend on dev-lang/go, because Go is very bad about static linking things, so all the Go bits that Docker needs were linked right into the installed Docker files.
I meant what I wrote. Go prefers to use static linking over dynamic linking. I consider this a bad thing. Static linking should be reserved to those rare situations when the drawbacks of static linking are clearly outweighed by its advantages. Mostly, this means that system recovery tools should be statically linked so that they can be used even when the system is broken. In my opinion, in almost all other cases, static linking is on balance worse than dynamic linking, and therefore should be avoided.
OK, so when you wrote "Go is very bad about static linking things" you meant that Go's usage of static linking is bad. I read it as static linking doesn't work very well with Go, and hence Docker linked Go dynamically. (Running ldd on the Docker binaries didn't show any dynamic linking against Go so I knew I misunderstood something.) Maybe I misread it because I'm not a native speaker of English. Thx for the quick reply, anyway.
"$noun is very bad about $action" is somewhat idiomatic, and means that $noun will tend to $action, even though this may not be a good idea. For example, "she is bad about gossiping" means that she gossips when that will cause problems, not that she is ineffective at engaging in gossip. I can see how a non-idiomatic reading would parse it as "$noun does $action in a low quality way."