From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id SESSHZKuFmefEQEAe85BDQ:P1 (envelope-from ) for ; Mon, 21 Oct 2024 19:42:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id SESSHZKuFmefEQEAe85BDQ (envelope-from ) for ; Mon, 21 Oct 2024 21:42:10 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729539730; a=rsa-sha256; cv=none; b=mlLvZDKq05U1PFDPARXLc48zo6NLwGDG60tenXlzePIG0YjbMpYgZHSEhYlZupSGiS7CVv 0k1JAyQXatqCeR477FyvWj0GHmEh3zJtd8Y3WVZmcDIQrHeWnbOEzWh8KxgcGkgRmbTH+d HYrJTJOLWdBZtDIBkb41wGzSd8RjapnXGFRmnuTBztZQR8luhTUoC+ykNbEfKJHWoZLlpS 1Fozlfvb3Yydgd2i/+LjOAmPS2jvonbef9Vtl2VCgy/+D6a4QHyBkUJHl3YzpC9yYDD8Tq wkDO7I1VeqtlnKccDuv0akYbQGMZHzoAp3jMupjn/os9U+gQfwGcui1xzPscig== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729539730; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=p0Uf0MUJyToJDFd9T0S/ZrVfyLQQY6aS+BZhgEX4LmI=; b=sCP2B7cIM5NUxMrfUF+syb23bJdm7NznhmYU/I5SCAE7SS70J+b7lMZ+l+owxVjAM0bNmq bHa3VylzO5p3sQgvElqXSCRLOtUhHNixxIAK9aweP13Cjw3/LO1vdeKRujtZzZzoea/Jb2 P3q9IT/jUZKFkEcmNN9KoEatGAPO2HRffcJzb61VuidGP1bjt5J0hllk90RfakcMZbJy/U juFufgjv1ZdtCxItYKQohSPgxt55V9JsBpD8aaAPwC25uplD7DkCyirT25++nAMcplxeuG 0nr8b84Gs3T2va6lr6Fxd92O+nwc+7vQwwXtglnLXkPV2jHUT9hPR3/DUN+ddQ== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0D4E87CED8 for ; Mon, 21 Oct 2024 21:42:09 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2yHY-0000F0-3r; Mon, 21 Oct 2024 15:41:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2yHV-0000Em-Gs for guix-devel@gnu.org; Mon, 21 Oct 2024 15:41:33 -0400 Received: from mx.sdf.org ([205.166.94.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2yHT-0000tW-2n for guix-devel@gnu.org; Mon, 21 Oct 2024 15:41:33 -0400 Received: from localhost ([172.59.219.2]) (authenticated (0 bits)) by mx.sdf.org (8.18.1/8.14.3) with ESMTPSA id 49LJWNZu015189 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 21 Oct 2024 19:33:40 GMT To: Andreas Enge Cc: "Denis 'GNUtoo' Carikli" , Superfly Johnson , guix-devel@gnu.org Subject: Re: Go Package with multiple subpackage In-Reply-To: (Andreas Enge's message of "Mon, 21 Oct 2024 16:18:56 +0200") References: <8f50a338-43e8-4142-90de-fb255686aaca.ref@yahoo.com> <8f50a338-43e8-4142-90de-fb255686aaca@yahoo.com> <20241018234328.58f7c0fa@primary_laptop> Date: Mon, 21 Oct 2024 15:32:17 -0400 Message-ID: <87a5exmev2.fsf@sdf.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=205.166.94.24; envelope-from=shcv@sdf.org; helo=mx.sdf.org X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Samuel Christie From: Samuel Christie via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.55 X-Spam-Score: -3.55 X-Migadu-Queue-Id: 0D4E87CED8 X-Migadu-Scanner: mx10.migadu.com X-TUID: QxMZGJYuJs6Q Andreas Enge 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