From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id LToFBg6pNmAsAQAA0tVLHw (envelope-from ) for ; Wed, 24 Feb 2021 19:29:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QEVHAQ6pNmALGQAAbx9fmQ (envelope-from ) for ; Wed, 24 Feb 2021 19:29:18 +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 63C6F18CED for ; Wed, 24 Feb 2021 20:29:17 +0100 (CET) Received: from localhost ([::1]:34672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lEzqW-0000wh-52 for larch@yhetil.org; Wed, 24 Feb 2021 14:29:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lEzhb-0002Ei-C5 for guix-patches@gnu.org; Wed, 24 Feb 2021 14:20:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52659) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lEzha-0003sP-Nc for guix-patches@gnu.org; Wed, 24 Feb 2021 14:20:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lEzha-0004dV-JV for guix-patches@gnu.org; Wed, 24 Feb 2021 14:20:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#44492] [PATCH 01/52] gnu: Add rust-ruma-identifiers-validation-0.1. Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 24 Feb 2021 19:20: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: Nicolas Goaziou Cc: 44492@debbugs.gnu.org Received: via spool by 44492-submit@debbugs.gnu.org id=B44492.161419438117789 (code B ref 44492); Wed, 24 Feb 2021 19:20:02 +0000 Received: (at 44492) by debbugs.gnu.org; 24 Feb 2021 19:19:41 +0000 Received: from localhost ([127.0.0.1]:35972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEzhF-0004cq-3t for submit@debbugs.gnu.org; Wed, 24 Feb 2021 14:19:41 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:42391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEzhC-0004cg-AR for 44492@debbugs.gnu.org; Wed, 24 Feb 2021 14:19:39 -0500 Received: from nijino.local (217-149-164-20.nat.highway.telekom.at [217.149.164.20]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Dm5MV3xLXz3xRh; Wed, 24 Feb 2021 20:19:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1614194374; bh=MvZF62tMR3h1wgs3lffqbRFyUDAazTM/c0xgCwvu6qQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=UaZrqSCretqdsJWnM133wk51WLvVa1y/8kB6DCYp0HKv1pitPP9IGA4JcTGbyG1nM zXuYNHn4rAc5pa1teKEUz01lj0hnbF4u2Nb/GKc8G7+K/qk6lauUwSrtKehocBlz6L K1yZ01PZmNHDeSJHOfoRWIxgI9wlTEosZ+vlQtTk= Message-ID: <3d7c689d5d0278b715dc3c2dc39a708b14e392e1.camel@student.tugraz.at> From: Leo Prikler Date: Wed, 24 Feb 2021 20:19:33 +0100 In-Reply-To: <87ft1lh4vh.fsf@nicolasgoaziou.fr> References: <87tuu2p37n.fsf@cbaines.net> <20210224111135.28883-1-leo.prikler@student.tugraz.at> <87sg5lhemw.fsf@nicolasgoaziou.fr> <87ft1lh4vh.fsf@nicolasgoaziou.fr> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 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: -1.27 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=UaZrqSCr; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=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: 63C6F18CED X-Spam-Score: -1.27 X-Migadu-Scanner: scn1.migadu.com X-TUID: f8A4l3vk8kMF Am Mittwoch, den 24.02.2021, 16:41 +0100 schrieb Nicolas Goaziou: > 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". Fair enough, I'll do so when I get to it. > > 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 think those two issues are related, but that's a discussion for guix- devel. So is the rest of this, but I might as well make my case here. > > 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. We could work developer inputs into the recursive importer, that should not be an issue. Honestly, it is a greater waste of time to recompile every dependency, have the build fail, change some minor thing in the package and recompile everything again. Yes, `guix build -K` helps to an extent, but it doesn't help if I made a typo in my build phase and got a guile backtrace. If cargo inputs worked like normal inputs, they'd be built reliably once and no time would be wasted rebuilding them over and over in any packages using them. > > 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. Maybe there'd be an argument if we had --no-skip-build, but I think we're working our way backwards here; trying work around a workaround. > 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 don't think there is any influence on the ease of definition, since either one would be handled by the recursive importer. The difficulty for packagers currently would be to manually undo the automatic build skipping done through the importer. As for reproducibility/security, there is yet little to gain, because the leaf crate can simply ignore its inputs and do whatever, but if we built the crates ahead of time, and disallowed the automatic building of dependencies, we would get efficient *and* reproducible Rust packages. Another thing that bugs me as a packager is that cargo inputs don't work for `guix refresh`, so I can't even be sure whether to put my patch to master or core-updates. > > 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. If skipping only some builds is not an option, you are either left with skipping all builds or skipping none, one of which is certainly silly. > 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. I personally hope that some of the issues resulting from this "wild west" approach to packaging will be alleviated by #46399. Having crates as regular inputs also increases the value of #:skip-build? #f. Regards, Leo