From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A1620138334 for ; Fri, 13 Sep 2019 02:17:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AEF6EE0C32; Fri, 13 Sep 2019 02:17:04 +0000 (UTC) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5C7EDE0AC0 for ; Fri, 13 Sep 2019 02:17:03 +0000 (UTC) Received: by mail-io1-xd2e.google.com with SMTP id a1so1514569ioc.6 for ; Thu, 12 Sep 2019 19:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PAvBmqIYS/GNl+oWLoikmUCqn9LXX/LFgho8I7Y7YLw=; b=qi+0wH59boGRBjcHqWFhgn7K9ZVWtU7RW/fLvmrPgfHGEO55TYv8aDgI6pqBoZrGkQ ELbhDoSsb+xZ0ejwxJ/6Bjq7SjlOHLXVwb4qDwlXyvgM3fjL1HLEKi9QE6SpDIID3Dn4 2tJ2yWBJ5bG7+28YFH/QnBvKlkbI0uUJFJl1ouNIMbQDWNnRqxvA6vMAGoNR+YquRaCf fQf3i/NvggQ9v8HtsTZ5rrZXZmMEyegHOb9QrfN5ewQOK5JeyJ0fCgQoetJ6OjhmZTqD P3BWCIaN8NBF/IbWDG4jrmILrkS4Pb9szdq6yu1BSY36fUeKlWJItC381d7YFR7+uywV v/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PAvBmqIYS/GNl+oWLoikmUCqn9LXX/LFgho8I7Y7YLw=; b=WrUw1ubp9UnAYqnBeysVq0FHd7RP/Y3Js8L30ZPxtTT6U5mOaxBsKsqqz1TCg/2mrQ BmfrN8F7/yF7ETrgZmRcXKKyq18L11KTrG4bGU+TsqlO0UCcpXRSFk9FwKDRknv/aIoj UmdzpQHIQEkyW5FZNPQyFSBB6wLVYqBDDd57IZLSaWz9KVlRBDJmMRA0lRx//lLGwEN8 HAhJ7HyuCR7geHeeULmNWmUXn7SktpLMQxPHqT7n3zWvrgN9ZrlN+7T3b1pVSxAPQPk/ cY/Nn8naBEgI58Cemb6SlQaoPzTNcKyDsn2UfmjnQcz/HCKfijOCOxinoxa/Ae47QCnQ IE/Q== X-Gm-Message-State: APjAAAX1n7YFPASlpiYhpc+Gi/Kmkbcsj29eL3MEzaHcPx8xptoyqTIP 0zyqjbJ3BYvBmm7hPFH1hc007mu9bU5J6+AvfDKlDZIL X-Google-Smtp-Source: APXvYqz2073A0P8CjwKbD/3BtbuTctgjSRjck/Gt9LD4waVsb4FBlhR90FSxSaNY3Q2dAW/Id9JUVi68mLpLG4Z5wko= X-Received: by 2002:a05:6602:cb:: with SMTP id z11mr8759702ioe.4.1568341021882; Thu, 12 Sep 2019 19:17:01 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-4-williamh@gentoo.org> <20190911234815.GA21591@whubbs1.dev.av1.gaikai.org> <20190912154634.GB23846@whubbs1.dev.av1.gaikai.org> <88094567-323c-6f6a-a1d9-0c1b77ef53e3@gentoo.org> <6acd490e-6393-62e4-5d07-71c2a3624417@gentoo.org> <2db31450-63e5-2ecc-ff3b-1858c760b287@gentoo.org> <4ccab80c-fc9e-c843-8a1b-50a329abf6c1@gentoo.org> In-Reply-To: From: Alec Warner Date: Thu, 12 Sep 2019 19:16:51 -0700 Message-ID: Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass To: Gentoo Dev Content-Type: multipart/alternative; boundary="0000000000007f12ed059265d941" X-Archives-Salt: 62449400-caaf-4645-90b0-4006c67ce4c5 X-Archives-Hash: ce213ce633c651b660b74ef8a4c30e2b --0000000000007f12ed059265d941 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 12, 2019 at 6:56 PM Alec Warner wrote: > > > On Thu, Sep 12, 2019 at 5:14 PM Michael Orlitzky 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 > > > --0000000000007f12ed059265d941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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 Orlit= zky <mjo@gentoo.org<= /a>> wrote:
O= n 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 t= he
best not very good solution.



Most people who build and package go= -based packages use static compilation, so we could in theory build dynamic= ally 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 diff= erent from what upstream is expecting.

https://docs.google.com/document/d/1nr-TQHw_er= 6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit=C2=A0describes the new execution= modes; it even discusses this very topic!

"This mode is mainly intended to support di= stro builders.=C2=A0 They can distribute Go packages or groups of packages = as shared libraries, and can thus update all Go programs by updating the sh= ared libraries, without requiring the programs to be relinked."=

Another thing I neglecte= d to point out is that even with these dynamic libs you end up with toolcha= in 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 g= o-N. Other languages have this problem as well, but its not great and it= 9;s a great recipe to hose a system while you are rebuilding your go progra= ms after an upgrade.
=C2=A0

I wonder who pushed for this to Ian, and whether distros ended up using th= is kind of target?

-A
<= div>

--0000000000007f12ed059265d941--