On Mon, 21 Oct 2024 16:18:56 +0200 Andreas Enge <andr...@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.
pgpGYX4gykbip.pgp
Description: OpenPGP digital signature
