[Fedora-packaging] Proposal to reduce anti-bundling requirements

[Lars Seipel]

On Thu, Sep 10, 2015 at 09:53:27AM -0400, Stephen Gallagher wrote:
> == Advantages to using shared libraries ==
>  * Security/Bugs - When a bug or security vulnerability is located in
> a library, it needs to be patched in only a single package in order to
> fix all applications using that library.
>  * Resources - A shared library only needs to be loaded into memory
> once, reducing the memory requirements of the system.

There's more to it. Not meaning shared libraries in particular, but
having a single "system copy" of a library. Whether these exist as
shared library, static library or source code doesn't matter as much.

A single library version that is used by all programs is a boon to the
transparency and simplicity of the system. It also makes it reasonably
straightforward for users to apply local patches and have the updated
library be used by all applications.

> == Advantages to bundling ==
>  * Increases the available pool of software that can be packaged
> substantially (many modern languages such as Ruby and Go are
> realistically only functional with allowable bundling)

Are you aware that there is work happening upstream to build Go packages
into shared libraries[0]? The explicit motivation of that work
(originating at Canonical) is to make maintenance of Go packages easier
for distributions. There's currently a single guy (Michael Hudson)
working on moving it forward. I wouldn't be surprised if he could do
with some help.

Also, I don't agree that Go code is only packagable with bundling. Sure,
the compiler emits static libraries but that doesn't mean you need to
bundle *source code* in different places. You can also ship the static
libraries (or better just the source code, as we already do) as a system
library for other packages to use.

The better Go libraries actually tend to strive for long-term (source)
compatibility. Or, if that doesn't work out, at least handle the
necessary transition thoughtfully. But yeah, as soon as you approach any
"web" stuff you might just run into the same Ruby crowd.

[0] technically, you can already build Go code into shared libraries but
you can only export a C API. Calling into Go code using a Go API is what
I meant above)