From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6JoYHo9XwmEnHgAAgWs5BA (envelope-from ) for ; Tue, 21 Dec 2021 23:39:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id CF30GY9XwmEDLAAA1q6Kng (envelope-from ) for ; Tue, 21 Dec 2021 22:39:11 +0000 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 1B5D811982 for ; Tue, 21 Dec 2021 23:39:11 +0100 (CET) Received: from localhost ([::1]:60880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mznmo-00050k-8H for larch@yhetil.org; Tue, 21 Dec 2021 17:39:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38020) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mznmg-00050I-4u for bug-guix@gnu.org; Tue, 21 Dec 2021 17:39:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:44422) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mznmf-0000fd-S2 for bug-guix@gnu.org; Tue, 21 Dec 2021 17:39:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mznmf-0007ja-QL for bug-guix@gnu.org; Tue, 21 Dec 2021 17:39:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#52684: [BUG] Multiple Packages Failing to Build Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 21 Dec 2021 22:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52684 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Christopher Rodriguez , 52684@debbugs.gnu.org Received: via spool by 52684-submit@debbugs.gnu.org id=B52684.164012629329674 (code B ref 52684); Tue, 21 Dec 2021 22:39:01 +0000 Received: (at 52684) by debbugs.gnu.org; 21 Dec 2021 22:38:13 +0000 Received: from localhost ([127.0.0.1]:55968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mznlt-0007iX-4p for submit@debbugs.gnu.org; Tue, 21 Dec 2021 17:38:13 -0500 Received: from baptiste.telenet-ops.be ([195.130.132.51]:46914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mznlr-0007iO-3x for 52684@debbugs.gnu.org; Tue, 21 Dec 2021 17:38:12 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by baptiste.telenet-ops.be with bizsmtp id ZAe82600G4UW6Th01Ae93y; Tue, 21 Dec 2021 23:38:09 +0100 Message-ID: From: Maxime Devos Date: Tue, 21 Dec 2021 22:38:08 +0000 In-Reply-To: <9c3a01d7-0c19-50c0-7492-dd9ff405ed85@gmail.com> References: <7ee7ed76-4676-6c86-87f0-8d7ab886fc50@gmail.com> <9c3a01d7-0c19-50c0-7492-dd9ff405ed85@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1640126289; bh=Gc/3SLqu6ZsH46DPvUc87v9GWVI0cToj3ppbU9ZJXak=; h=Subject:From:To:Date:In-Reply-To:References; b=MkI/Qg8d7rvSQJVacbyekqKGYxVGCGr4/5msQ1+MgOAfHeaF52epA+n+qSk5xh7u9 VG2fDjGPiJHEPzCm3x5c9VCQ/46t6ps5XxtgONjyY2AvfxPKtfvh4qTJ8D62jXcBNn CbA/1vf8V3bbcSkhiFTKh8RZtbG7ceI8RSpHS23BZHPGKqykijB1xuk5odOxUgLLvW dtgp+X7oun3ih8n4NWDQOfr4L8DDaywUrw1j5j/zfTadJ6AJLgEXTur2+kqhkUVVpO yV1HkmJP1KpAH8W3QdZq0Xfh1mvoOFwypvbZ2Oj9GDx2ljGmlLnzX5nLx79MEVd1Hi B2RTJG1n7RA4Q== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640126351; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Gc/3SLqu6ZsH46DPvUc87v9GWVI0cToj3ppbU9ZJXak=; b=KZuqYvELLM6jA/E9/f5KvkCTv5dVRbN3/6BSRM9AzKe0gcY0ZUGQWTWNJaRvNKb80mni1h T4nwkMJWN0tOfjlUH479DzviDWr22lcTDBANB070N6fIdLtNsOAPOLUXeShfmePy0fnoQ5 Yto1h7BT+FohEo1XKa4JM75oMKK5uvs7tSYKgNxeCl9wZV92tlYdiwWv3a9oDbMD2LJbZJ +Z1uubLXeOQbyrFH3ifRFlQErosEjs9gpWdbMDBTc7BvK+a20T7Uaa18OxHgk7sSEOVQnR g90NtqZPAe5OQRqH1xzhMoZEAKeHSI6p2/uQmda2fOoy59cZXZp/lE7OAXdMgw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640126351; a=rsa-sha256; cv=none; b=kZvtkas7+vn23XSsOJbojvmDljf3WhyRMPNRazecYWlCZTrL8dEu9YAefG2o7IzdqhLzaX gGb2V+cj+LApdV7Bz1uqIQ6b9hIJ9mxgqeZFEFXoM7MMrfILeWuZPouadDJR2jz2RSvGCM pECB8kncZis4aS3/pAzpoiE0TPcKeYjUjowfd+wNIp2PzddQa++p7X4a4/BvOKl6i8kwkW e7SieyB7nt6zHebGOmX+wjZqsS61geMjstSDG7tXhfgvvQG2HCPcHmQmKJyX7NmP5UkWVk 1NQpe9JYe+5VMG0y8FSMKj7m4Tpg9PADgV3tzcAkeqwS4ZSraG3jZ1wjI95+mg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r21 header.b="MkI/Qg8d"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.03 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r21 header.b="MkI/Qg8d"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 1B5D811982 X-Spam-Score: -2.03 X-Migadu-Scanner: scn0.migadu.com X-TUID: j1tjEjdpHDSK Christopher Rodriguez schreef op di 21-12-2021 om 16:38 [-0500]: > Ah, I see. That makes sense. > > However, I don't think we need to necessarily use all of 'beets' inputs > as inputs for 'beets-bandcamp', because it will build fine with just the > inputs listed. I know it isn't DRY, but it seems like the most efficient > way to define the package might be to simply define the packages it is > expecting to see, and only those packages: I don't have a strong opinion here. > That way, should someone > install 'beets' and then 'beets-bandcamp' at a later time, they don't > need to download unused inputs (like, for instance, 'python-rarfile'). This doesn't hold: if someone installs beets and beets-bandcamp, then they need to download python-rarfile in any case, because beets has python-rarfile as a reference (see later). > That said, I suppose at least 'beets' needs to be a propagated-input for > 'beets-bandcamp', because IIUC the main difference between the > propagated-inputs and inputs is that inputs are used only at build time > (like 'BuildRequires' in RPM), whereas propagated-inputs are pulled in > as installed dependencies (like 'Requires' in RPM). 'beets' would need > to be a propagated-input because 'beets-bandcamp' is a plugin for > 'beets', and requires 'beets' to function as expected. Is that correct? This is vaguely correct in some ways but also incorrect in other ways. At guix core, the only runtime dependency mechanism is references, and there's no concept of ‘build-time only’. Basically, if the store item /gnu/store/xxxx has a file that contains the string /gnu/store/yyyy, then /gnu/store/xxxx is said to have a reference to /gnu/store/yyyy. Also, whenever a store item /gnu/store/xxxx is substituted, its reference /gnu/store/yyyy is substituted as well. And having /gnu/store/xxxx in the store prevents /gnu/store/yyyy from being garbage collected. This works very well for C and C++ things, where we have nice things like RUNPATH for libraries and other binaries. But for python, guile, etc. things, there's a snag: the ‘compiled code’ is (almost) exactly the source code shuffled around in some directory (possibly with bytecode compilation, but the bytecode typically doesn't have an equivalent to RUNPATH), so Guix doesn't find a reference between /gnu/store/xxxx and /gnu/store/yyyy. To work around this, there's propagated-inputs: if 'xxx' has 'yyy' in its propagated-inputs, then whenever 'xxx' is installed in a profile, 'yyy' is installed in the profile as well. (This is very different from ‘classical’ distros!) About letting 'beets-bandcamp' propagate 'beets': that would make some amount of sense, but we don't let, say 'emacs-minion' propagate 'emacs', we don't let 'python-six' propagate 'python'. That is, when the user asks to install a plugin, we currently only install the plugin and not the application it extends. A bug? Maybe, because a plugin is useless without the corresponding applications. Maybe not, because propagated-inputs are inconvenient in many ways in Guix; they are a work-around to be avoided. In any case, this is not specific to beets, so if you'd like to change this, I suggest starting a thread on guix-devel. > If so, I am unsure why the other originally propagated-inputs were > listed as such when they weren't needed for beets to function. (The non-optional ones) are needed for beets to function. How did 'beets' find its dependencies then when they aren't propagated? Because 'beets' was wrapped to set GUIX_PYTHONPATH (see 'wrap' in python-build-system.scm), and because of references (see above). > I just > built beets-bandcamp with everything listed as a propagated-input in my > patch moved to an input, and it built fine. Is there a way I could > install that built version to test it, to ensure none of the inputs need > to be propagated-inputs (aside from 'beets')? A pure temporary environment (guix shell --pure beets beets-bandcamp -- beet $do-stuff-with- bandcamp) can be useful. Not sure about what '$do-stuff-with-bandcamp' would be, I'm not familiar with beets. > Please let me know if I'm way off base here; I'm very new to packaging > in GNU/Guix! (And thank You for the help while I learn!) > > As for the GUIX_PYTHONPATH and GUIX_BEETSPATH idea, I would love to > implement something like that here, but I am running against my > inexperience here, and was unable to find useful docs on defining PATHs > or 'wrap-program' (I haven't looked exhaustively yet, but only have so > much time in the day to do so, unfortunately). > > Could You point me to some resources to explain the mechanisms involved > in defining PATHs, or on the 'wrap-program' function? I am more than > willing to learn. It appears that 'search-path-specification' is not documented in the manual, but you could look at (guix search-paths) and look for examples in packages (git grep -F search-path is useful). 'wrap-program' is unfortunately undocumented as well. Anyway, a separate GUIX_BEETSPATH isn't strictly necessary, though I believe it would be a slight improvement. But now I think about a bit more, I don't think it would be useful, because GUIX_BEETSPATH and GUIX_PYTHONPATH would look in the same subdirectories anyway ... (Search paths are bound to the ‘consuming’ package, not the ‘providing’ package.) Greetings, Maxime.