qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v3 13/32] rust: use vendored-sources


From: Daniel P . Berrangé
Subject: Re: [RFC v3 13/32] rust: use vendored-sources
Date: Thu, 9 Sep 2021 17:53:44 +0100
User-agent: Mutt/2.0.7 (2021-05-04)

On Thu, Sep 09, 2021 at 08:29:58PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Sep 9, 2021 at 8:04 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> 
> > On Tue, 7 Sept 2021 at 13:32, <marcandre.lureau@redhat.com> wrote:
> > >
> > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >
> > > Most likely, QEMU will want tighter control over the sources, rather
> > > than relying on crates.io downloading, use a git submodule with all the
> > > dependencies. However, cargo --offline was added in 1.36.
> > >
> > > "cargo vendor" helps gathering and updating the dependencies.
> > >
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > ---
> > >  configure                 | 8 ++++++++
> > >  meson.build               | 7 ++++++-
> > >  .cargo/config.toml.in     | 5 +++++
> > >  .cargo/meson.build        | 5 +++++
> > >  .gitmodules               | 4 ++++
> > >  rust/vendored             | 1 +
> > >  scripts/archive-source.sh | 2 +-
> > >  scripts/cargo_wrapper.py  | 1 +
> > >  8 files changed, 31 insertions(+), 2 deletions(-)
> > >  create mode 100644 .cargo/config.toml.in
> > >  create mode 100644 .cargo/meson.build
> > >  create mode 160000 rust/vendored

> > Overall, I think that to the extent that we can look like a "normal"
> > user of Rust, that's a good plan. Distros may well want to be able
> > to do "build against our packaged rust stuff rather than downloading
> > from crates.io" but I imagine they have machinery for that already;
> > if we act like most other Rust programs we have better chances of
> > not breaking that machinery.
> >
> 
> True, at least on Fedora, there is machinery to package "regular" Rust
> programs/crates in an automated way.  Vendoring dependencies should work
> equally, but may not conform with distro policies, so they have extra work
> eventually (it seems vendoring is more and more common though, with go
> projects for example)

I wouldn't assume that we're going to be able to use that RPM support
for rust, if we bundle our rust code inside the QEMU tarball and hidden
behind meson. It generally only works well in single language projects
using the preferred build tool exclusively (Cargo in this case).

> > (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 :-))
> >
> >
> 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.

The Cargo metadata specifies the versions we'll get so we have full
control over what deps are pulled in. All the mirroring our do is to
cope with occassions where the main crate download website is
inaccessible for some reason. I'm not convinced that's enough to
justify creating extra work for ourselves through mirroring. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]