From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9934DC433F5 for ; Thu, 9 Sep 2021 17:04:41 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id EF85561100 for ; Thu, 9 Sep 2021 17:04:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EF85561100 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xenproject.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:59366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mONTb-0004lk-RH for qemu-devel@archiver.kernel.org; Thu, 09 Sep 2021 13:04:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mONRg-00042F-4o for qemu-devel@nongnu.org; Thu, 09 Sep 2021 13:02:40 -0400 Received: from mail.xenproject.org ([104.130.215.37]:42326) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mONRe-000533-6L for qemu-devel@nongnu.org; Thu, 09 Sep 2021 13:02:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=References:In-Reply-To:Subject:Cc:To:Date :Message-ID:Content-Transfer-Encoding:Content-Type:MIME-Version:From; bh=W+eL+NjEJ/HA6q2sb1NNE1A3+f7cB91NgzelvR9305A=; b=U3B44G+nDi42iOKO5PAfU2x6GK yAtJr+bHPR4DupBmqu3dFRM0ntuIN1WQHWeM3Cb3ke6LzNo901RrSRvHiq1YzDUPvtPsdITQTiPn1 dSo9V0qWvNidg12WrU/pL1ZinyY12rMoSTYvajq3IS1vX6n09hMxjSHMKM+8rqSHDqyo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mONRb-0002f4-Or for qemu-devel@nongnu.org; Thu, 09 Sep 2021 17:02:35 +0000 Received: from iwj (helo=mariner.uk.xensource.com) by xenbits.xenproject.org with local-bsmtp (Exim 4.92) (envelope-from ) id 1mONRb-00070S-Nk for qemu-devel@nongnu.org; Thu, 09 Sep 2021 17:02:35 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.89) (envelope-from ) id 1mONRV-0006y3-8t; Thu, 09 Sep 2021 18:02:29 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <24890.15908.689806.862379@mariner.uk.xensource.com> Date: Thu, 9 Sep 2021 18:02:28 +0100 To: Daniel P. =?iso-8859-1?Q?Berrang=E9?= Subject: Re: [RFC v3 13/32] rust: use vendored-sources In-Reply-To: References: <20210907121943.3498701-1-marcandre.lureau@redhat.com> <20210907121943.3498701-14-marcandre.lureau@redhat.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) Received-SPF: pass client-ip=104.130.215.37; envelope-from=iwj@xenproject.org; helo=mail.xenproject.org X-Spam_score_int: -63 X-Spam_score: -6.4 X-Spam_bar: ------ X-Spam_report: (-6.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.975, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , QEMU Developers , Markus Armbruster , Stefan Hajnoczi , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Daniel P. Berrangé writes ("Re: [RFC v3 13/32] rust: use vendored-sources"): > Yes, distros do have machinery for this, although it is often > hard to fit in with it when you have a mixed language project. > Their machinery typically assumes pure single language project, > so would work nicer if any QEMU rust pieces were separately > released from the rest of QEMU. Obviously this is easier said > than done since QEMU tends towards a monolothic repo approach > historically. Right. However, for a project that has Rust dependencies, the distros will (or will soon need) machinery to divert the langage-specific-package-manager downloads to their own repo. For example, the Debian Rust team provide a .cargo/config.toml to replace crates.io with the local Debian Rust packages, which the Debian package management system has provided via the (translated) build-dependencies. Debian certainly wouldn't want to use any vendored crates bundled with Qemu. Indeed Debian people hate vendoring more than they hate language specific package managers. At least with the LSPM you can usually nobble it in one place - ie many of the problems can be solved automatically. Vendoring typically involves playing whack-a-mole with compatibility problems, actually-modified versions, etc. - much human work (and quite annoying work too!) (Of course this is less of an issue if you don't actually modify the vendored code, but anyone who knows Rust and sees a vendored Rust crate will think it's been modified.) > > (I'm not personally a fan of the "download everything from crates.io" > > Rust ecosystem, but it is what it is, and wishing the Rust world > > worked more like a trad Linux-distro-provides-all-your-dependencies > > isn't, alas, going to make it so :-)) > > Yes, I'm inclined to agree here. For better or worse the battle is > over and "download everything from on the fly" is the accepted > approach for pretty much all modern languages. The language specific > repo essentially is the OS distro from their POV. To be honest, I am of the same mind as you about cargo and crates.io (and things like it) But I think the ship has sailed. At least, committing the Cargo.lock file will ensure that the same versions of the dependencies are used - at least by people who don't know anything much about Rust. Marc-André Lureau writes ("Re: [RFC v3 13/32] rust: use vendored-sources"): > A nice alternative to vendoring that could work well for QEMU is to > mirror the Rust crate we use, so we have similar control and > guarantee over them as submodules, and use `[patch.crates-io]` to > point at qemu-project locations. This is a very reasonable suggestion. In my experience crates.io is very reliable - but (as a test system onwer myself) I know how much you want to reduce the number of different sites whose upness your CI depends on, no matter how good their communities think they are :-). I think there should be a documented config option to disable this. People who know enough Rust to run `cargo update` etc. will need it, and having them hand-hack the config files is not really desirable. Ian.