From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QVl1D9ZzNmABBAAA0tVLHw (envelope-from ) for ; Wed, 24 Feb 2021 15:42:14 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 8H7MCtZzNmA/GAAAB5/wlQ (envelope-from ) for ; Wed, 24 Feb 2021 15:42:14 +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 824B6277EB for ; Wed, 24 Feb 2021 16:42:13 +0100 (CET) Received: from localhost ([::1]:60940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lEwIm-0002sQ-Lg for larch@yhetil.org; Wed, 24 Feb 2021 10:42:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lEwIc-0002q3-VC for guix-patches@gnu.org; Wed, 24 Feb 2021 10:42:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52200) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lEwIc-0004KA-J1 for guix-patches@gnu.org; Wed, 24 Feb 2021 10:42:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lEwIc-0007aj-Ek for guix-patches@gnu.org; Wed, 24 Feb 2021 10:42:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#44492] [PATCH 01/52] gnu: Add rust-ruma-identifiers-validation-0.1. Resent-From: Nicolas Goaziou Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 24 Feb 2021 15:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44492 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: moreinfo To: Leo Prikler Cc: 44492@debbugs.gnu.org Received: via spool by 44492-submit@debbugs.gnu.org id=B44492.161418130429156 (code B ref 44492); Wed, 24 Feb 2021 15:42:02 +0000 Received: (at 44492) by debbugs.gnu.org; 24 Feb 2021 15:41:44 +0000 Received: from localhost ([127.0.0.1]:35513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEwIK-0007aC-9K for submit@debbugs.gnu.org; Wed, 24 Feb 2021 10:41:44 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:38291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEwIH-0007Zv-Gy for 44492@debbugs.gnu.org; Wed, 24 Feb 2021 10:41:42 -0500 X-Originating-IP: 185.131.40.67 Received: from localhost (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4EC47E0009; Wed, 24 Feb 2021 15:41:33 +0000 (UTC) From: Nicolas Goaziou Message-ID: <87ft1lh4vh.fsf@nicolasgoaziou.fr> References: <87tuu2p37n.fsf@cbaines.net> <20210224111135.28883-1-leo.prikler@student.tugraz.at> <87sg5lhemw.fsf@nicolasgoaziou.fr> Date: Wed, 24 Feb 2021 16:41:32 +0100 In-Reply-To: (Leo Prikler's message of "Wed, 24 Feb 2021 14:13:29 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.37 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 824B6277EB X-Spam-Score: -2.37 X-Migadu-Scanner: scn1.migadu.com X-TUID: cTG9OKaEvzC9 Leo Prikler writes: > I was afraid this would cause rebuilds for the existing package. Was > that fear unfounded? I don't think it would change anything. It is what we usually do in "crates-io.scm". > I personally disagree. The only reason a crate failing to build is a > "valid input" to another is because that other crate can decide to > completely disregard it, which sounds neither "reliable" nor > "efficient" for a programming language, that prides itself as both. Probably, but the problem at hand is not to fix how Rust builds its crates, but rather optimize Rust packaging. > I will only skip builds for dead crates, i.e. crates I can reasonably > assume to only contain dead code due to their build failures. This > does not seem to cost much when building dependant packages, as I've > found that in order to actually build the crates I have to explicitly > invoke `guix build `. There's much more work involved. You have to take care of development inputs which increases drastically the number of crates to package. Moreover, you need to try building each of them, which takes time. Not skipping builds makes de facto some packages impossible to package. > Of course, there's still the problem of CI. Long-term, I think we > should find a way for this efficient programming language to reliably > produce reusable build artifacts. Short term, hitting non-leaf > packages, that have cargo-build-system anywhere with a priority of > negative infinity sounds like a better workaround. I want to be able > (as a developer) to explicitly build crates and determine where they > fail. As a packager, you don't need to build the crate to fix any issue arising at a higher level, as I pointed out already. If you're developing the crate, that's another story. But then, you can quickly write your own package definition. I think the real questions about building intermediate crates, from a packager point of view, are: - does that make the packages reproducible? - does that make the packages more secure? - does that make the packages easier to define? >From my experience, the answer is "no" to any of these. This is a net loss. > I believe we should not cowtow to Rust and Cargo, but instead force > them to adhere to our principles; principles of building applications > *and* libraries reproducibly without encoding hashes in a huge ass-lock > file. I don't think it is worth focusing of this. We currently do a good job in Rust packaging, really. But it doesn't make much sense to have some packages skipping builds and not some others. What saddens me a bit is that individuals (including me, of course) are currently doing as they see fit, but we haven't so far decided, as a group, how to deal with the question uniformly. I hope we can converge quickly. Regards,