From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
Date: Thu, 12 Sep 2019 19:16:51 -0700 [thread overview]
Message-ID: <CAAr7Pr_tFsm6Mu4JfT8KAcBBbSVCpXPOKS-zTNDMdZHJfXgC2A@mail.gmail.com> (raw)
In-Reply-To: <CAAr7Pr9py+=wD8LxRUzZ=v0wFogXR3_NbaoWQBLOwrtFXVAorA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
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
>
>
>
[-- Attachment #2: Type: text/html, Size: 3769 bytes --]
next prev parent reply other threads:[~2019-09-13 2:17 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 17:21 [gentoo-dev] [PATCH 0/3] add eclass to handle go modules William Hubbs
2019-09-11 17:21 ` [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new " William Hubbs
2019-09-11 17:38 ` Michał Górny
2019-09-11 18:22 ` William Hubbs
2019-09-11 18:31 ` Michał Górny
2019-09-11 19:40 ` William Hubbs
2019-09-11 19:47 ` Michał Górny
2019-09-11 23:11 ` William Hubbs
2019-09-12 5:39 ` Michał Górny
2019-09-12 16:39 ` William Hubbs
2019-09-12 17:03 ` Michał Górny
2019-09-12 20:16 ` Kent Fredric
2019-09-12 21:10 ` Michał Górny
2019-09-11 23:31 ` Alec Warner
2019-09-12 0:05 ` William Hubbs
2019-09-12 0:28 ` Alec Warner
2019-09-12 15:36 ` William Hubbs
2019-09-12 20:20 ` Kent Fredric
2019-09-12 20:38 ` Alec Warner
2019-09-12 21:12 ` Michał Górny
2019-09-12 22:01 ` Alec Warner
2019-09-13 9:13 ` Kent Fredric
2019-09-11 17:21 ` [gentoo-dev] [PATCH 2/3] app-misc/spire: migrate to go-module.eclass William Hubbs
2019-09-11 17:21 ` [gentoo-dev] [PATCH 3/3] dev-vcs/hub: " William Hubbs
2019-09-11 17:39 ` Michael Orlitzky
2019-09-11 17:47 ` William Hubbs
2019-09-11 17:48 ` Michael Orlitzky
2019-09-11 19:15 ` Kent Fredric
2019-09-11 19:26 ` William Hubbs
2019-09-11 23:34 ` Alec Warner
2019-09-11 23:48 ` William Hubbs
2019-09-12 0:05 ` Alec Warner
2019-09-12 15:46 ` William Hubbs
2019-09-12 16:14 ` Michael Orlitzky
2019-09-12 16:42 ` Alec Warner
2019-09-12 16:52 ` Michael Orlitzky
2019-09-12 16:55 ` Mike Gilbert
2019-09-12 17:05 ` Michael Orlitzky
2019-09-12 17:43 ` Mike Gilbert
2019-09-12 21:11 ` Michael Orlitzky
2019-09-12 21:23 ` Mike Gilbert
2019-09-13 0:14 ` Michael Orlitzky
2019-09-13 1:56 ` Alec Warner
2019-09-13 2:16 ` Alec Warner [this message]
2019-09-13 3:13 ` Mike Gilbert
2019-09-13 12:11 ` Michael Orlitzky
2019-09-12 17:45 ` Alec Warner
2019-09-12 21:58 ` Michael Orlitzky
2019-09-13 9:19 ` Kent Fredric
2019-09-13 12:29 ` Michael Orlitzky
2019-09-13 20:17 ` Patrick McLean
2019-09-13 23:44 ` Michael Orlitzky
2019-09-14 0:22 ` Patrick McLean
2019-09-14 17:06 ` Alec Warner
2019-09-14 22:37 ` Michael Orlitzky
2019-09-16 7:54 ` Kent Fredric
2019-09-14 6:52 ` Ulrich Mueller
2019-09-13 16:50 ` Michael Orlitzky
2019-09-13 20:52 ` Patrick McLean
2019-09-16 8:11 ` Kent Fredric
2019-09-12 20:10 ` Kent Fredric
2019-09-12 17:31 ` Michał Górny
2019-09-12 16:46 ` Alec Warner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAr7Pr_tFsm6Mu4JfT8KAcBBbSVCpXPOKS-zTNDMdZHJfXgC2A@mail.gmail.com \
--to=antarus@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox