Hacker News Reader

Comment by cbmuser | Hacker News Reader

> Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense.

The problem is that distributions get their software from upstream developers. And if upstream decides to go static or use embedded code copies, the maintainers have much more work trying to untangle everything.

In my experience, packaging Go software for Linux distributions is very frustrating and tedious because of that.

Packaging Python or C/C++ software is much easier.

View on HN

This is ironic, because Go in much easier to build than C or C++, especially since the introduction of Go modules.

Perhaps this "untangling" isn't the best idea, at least not always?

Unbundling is often necessary due to these issues:

- the bundled things might have unclear licensing

- bundling stuff that is available in the repos is sub optimal, as the repo version will be updated for security issues while the bundled version will not

- you can use some mechanism to mark what stuff is bundled in a package, but then you need to make sure the bundled thing is patched and rebuild each thing bundling it, where with system wide dependency you just update that and you are done

It's pretty rare there are parts with "unclear" licensing. Does it happen? Sure. But "often"?

I'm fairly sure that almost all projects are receptive to updates for dependencies with security issues; I don't see why a distro needs to "untangle" anything for them.

> with system wide dependency you just update that and you are done

Unless the system-wide update won't work with your program.

The entire point of the Go tooling is that you can reliably and consistently build your software, and replacing random parts to create a weird unsupported (by the actual developers anyway) version is something the Go tooling was never designed to support: it goes exactly against what it was designed to do. Hence my previous comment: perhaps this isn't the best of ideas.

This talk (from 2011 but still very relevant today) mentions some if the licensing and other issues package maintainers have to face:

https://www.youtube.com/watch?v=fRk97h1FLow

is it really that bad to distribute statically-linked go binaries in a distro? Or rather, perhaps the better question - what's the dynamic linking benefit that a distro can't live without?

Wondering since the application developers I know seem to prefer static linking.

Security fixes, for one. It's more convenient to rebuild one shared library instead of having to rebuild all downstream consumers.

hm, fun. That seems understandable given the status quo.

I can't help but wonder if we'd all just benefit from better build systems, so that "rebuilding all downstream consumers" wouldn't be hard.

The just leave it out of your distribution's repo. If it is a static binary then it is already easy to distribute so no one needs the repo.

Reply on news.ycombinator.com