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.
Wondering since the application developers I know seem to prefer static linking.
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.
Perhaps this "untangling" isn't the best idea, at least not always?
- 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
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.
They're screwed. Hopefully you aren't.
Hopefully.