GNU bug report logs -
#74049
[PATCH v1] gnu: matterbridge: Unbundle most golang.org dependencies.
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Sun, 27 Oct 2024 20:26:03 +0000
Sharlatan Hellseher <sharlatanus <at> 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.
[Message part 2 (application/pgp-signature, inline)]
This bug report was last modified 266 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.