On Thu, Sep 12, 2019 at 6:56 PM Alec Warner <antarus@gentoo.org> wrote:

>
>
> On Thu, Sep 12, 2019 at 5:14 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
>> On 9/12/19 5:23 PM, Mike Gilbert wrote:
>> >
>> > Putting the dependencies in RDEPEND means users get stuck with yet
>> > another copy of the code installed, in addition to the copy that is
>> > statically linked into all reverse dependencies.
>> >
>> > It's not a very good solution to the problem.
>> >
>>
>> No argument there. The elegant solution to static linking is to not do
>> it. But I guess that's off the table? So now we're trying to find the
>> best not very good solution.
>>
>>
> Well I think you end up with a weird tradeoff here.
>
> Most people who build and package go-based packages use static
> compilation, so we could in theory build dynamically linked executables,
> but then we diverge from the upstream practice.
> Maybe this is the right approach, but I think its a bunch of extra
> engineering work (to make things build dynamically) and will be pretty
> different from what upstream is expecting.
>
>
> https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit describes
> the new execution modes; it even discusses this very topic!
>
> "This mode is mainly intended to support distro builders.  They can
> distribute Go packages or groups of packages as shared libraries, and can
> thus update all Go programs by updating the shared libraries, without
> requiring the programs to be relinked."
>

Another thing I neglected to point out is that even with these dynamic libs
you end up with toolchain problems. Once you upgrade you go toolchain (goN
and go-N+1) and build a new libfoo with go-N+1, it becomes incompatible
with binaries built with go-N. Other languages have this problem as well,
but its not great and it's a great recipe to hose a system while you are
rebuilding your go programs after an upgrade.


>
> I wonder who pushed for this to Ian, and whether distros ended up using
> this kind of target?
>
> -A
>
>
>