Re: Go Package with multiple subpackage

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

On Mon, 21 Oct 2024 16:18:56 +0200
Andreas Enge <andreas@enge.fr> wrote:
> > As I understand, packaging too many dependencies would create
> > complications for the maintenance.
> 
> Is that true? It looks opposite to the general Guix philosophy;
> once you have invested all the work of checking the licenses, it would
> seem a progress to submit the corresponding packages. But maybe Go is
> special in that respect; it would be nice to have the Go team's
> opinion.
One of the issue is also that I didn't find a way to have a path where
things are done step by step, so adding about 500 extra packages just
for the matterbridge package would be complicated I guess.

But in another hand using bundled in dependencies doesn't look great
either.

This also bring in more complicated questions as there is also some
tradeoffs made here. 

For instance here things are not fine with matterbridge but it's not
something a user can immediately see. So should we keep the package?
What would be the quality of the maintenance in the long run with
about 500 packages to update?

I've also no idea about how many go packages use bundled dependencies,
so maybe if there is a way to somehow un-bundle part of the
dependencies it could be a road to improve the situations as the
maintenance the dependencies shared by many go packages could be shared
somehow (assuming people do check that when updating things it doesn't
break other packages).

If packages also patch some dependencies, it would not prevent from
using non-bundled dependencies.

Another issue is that all that is statically built but that's part of
the default go compiler if I understood well, though given how Guix
works, it might easier to somehow use shared libraries (compared to
more standard distributions) if some compilers that support that since
we don't need very strict/strong ABI guarantees with Guix, and thanks
to that, reduce build times and resources consumption (like RAM, space,
etc).

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]