Andreas Enge <andr...@enge.fr> writes:
Am Fri, Oct 18, 2024 at 11:43:28PM +0200 schrieb Denis 'GNUtoo'
Carikli:
And given the number of dependencies I was told that it was
okay to have them bundled in.
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.
I am slightly interested in this question as well.
On the one hand, it seems like taking reproducible builds
seriously requires not only pinning all of the sources but also
archival etc. Guix seems to handle that right now by absorbing
dependencies as packages. However, this implies that Guix has to
assimilate all packages from all other package managers, which
doesn't sound sustainable.
On the other hand, assuming the foreign package repository
properly supports pinning and retrieving exact older versions of
the source, it seems plausible to fetch those dependencies as a
bundle during preparation. This would simplify packaging, but
bundling dependencies may result in duplication. (Unless each
dependency can be fetched as a separate store entry to
deduplicate?) Unlike old NPM though, we wouldn't be recursively
pulling in dependencies, just once per application.
It sounds to me like doing this properly would require
build-system support, and possibly explicitly pulling in each
foreign dependency for pinning and deduplication. The challenge is
ensuring that all of those dependencies are properly licensed
source code; it would be easy to leak in binaries as shortcuts.
I'm sure this has been discussed before and I just missed it. Are
there clear guidelines on when/how to bundle dev dependencies vs.
packaging them separately?
--
Samuel H. Christie V
