From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: Sharlatan Hellseher <sharlatanus@gmail.com>
Cc: 74049@debbugs.gnu.org
Subject: [bug#74049] [PATCH v1] gnu: matterbridge: Unbundle most golang.org dependencies.
Date: Mon, 28 Oct 2024 14:00:01 +0100 [thread overview]
Message-ID: <20241028140001.1d996969@primarylaptop.localdomain> (raw)
In-Reply-To: <87iktduwbo.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]
On Sun, 27 Oct 2024 20:26:03 +0000
Sharlatan Hellseher <sharlatanus@gmail.com> wrote:
> Thanks for the initiation of unbundeling process for materbridge!
Thanks a lot for the review.
> A general comments for Golang packages which is just final binary, you
> may apply "#:install-source? #f" parameter which mean do not place
> source of the project into store and just move produced binary.
Thanks, I'll do that in a newer patch.
> Also for the final binary all build inputs may be placed to
> "native-inputs" they will never be used elsewhere after the install
> phase.
Right, I just copied a bit what was done in the example I followed, so
that might need to be fixed as well.
Using inputs didn't look right to me but it was done in this way so I
assumed that there was a good reason for it (I tried unbundling long
time ago and it didn't work at the time, but maybe I was just unlucky).
> While you are keen to unbundle let's pick up as many as we can. You
> may also add some other inputs which are available already:
I was already unsure about the patch I sent. In the v2 should I do it
all at once in a single patch or should I split the work across multiple
patches?
The advantage of the former is that it becomes easier to bisect issues.
The downside is that if the granularity is too small, I fear that we'll
end up with hundreds of patches.
So I also think it's a good idea to agree on how to make these changes
before doing more and more patches. For instance you could validate one
patch (without necessarily pushing it) so I could use that as a
blueprint for the next ones and not have to redo all the work for so
many patches.
Here I picked something in between where I grouped the unbundling of
dependencies by selecting something they had in common, but I've no
idea if it's the right way to do it.
Also note that I ran the resulting binary, but without feeding it a
configuration. I'll do a more complete test later on as tests are quite
expensive: I need to install Guix on the production server, update it,
build the matterbridge package, and uninstall guix after that to reduce
the attack surface.
> - filippo.io/edwards25519
> - go.uber.org/multierr
> - gopkg.in/ini.v1
> - gopkg.in/natefinch/lumberjack.v2
> - gopkg.in/natefinch/lumberjack.v2
> - gopkg.in/yaml.v2
> - gopkg.in/yaml.v3
> - google.golang.org/protobuf
> - github.com/hashicorp ;; all of them are available
> - github.com/golang/protobuf
> - github.com/fatih/color
> - github.com/google/uuid
> - github.com/gorilla/websocket
> - github.com/pkg/errors
Thanks, I found some of them like the protobuf one but I didn't add
them in my patch yet.
> Basically we targeting to have just the first level of dependentices
> in "native-inputs" as seen in
> <https://github.com/42wim/matterbridge/blob/master/go.mod>.
OK, I didn't look at that yet, I just started looking at what was in
vendor/ with a script and made a patch with the group that is closer to
the language (golang).
> Please take a look if removing them from vendor and adding them to
> native-inputs still keeps the build green.
Thanks for the additional list, I'll definitely do that.
Denis.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-10-28 13:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-27 18:12 [bug#74049] [PATCH v1] gnu: matterbridge: Unbundle most golang.org dependencies Denis 'GNUtoo' Carikli
2024-10-27 20:26 ` Sharlatan Hellseher
2024-10-28 13:00 ` Denis 'GNUtoo' Carikli [this message]
2024-10-28 21:56 ` Sharlatan Hellseher
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=20241028140001.1d996969@primarylaptop.localdomain \
--to=gnutoo@cyberdimension.org \
--cc=74049@debbugs.gnu.org \
--cc=sharlatanus@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.