What if librsvg did not vendor its dependencies?

Platform
1

Since librsvg started including Rust code, its release tarballs have come with the Rust dependencies bundled in, thanks to the cargo vendor machinery. This is why the source tarball is so big.

I’ve noticed that some other Rust projects (e.g. rav1e) don’t bundle their dependencies, and that distros now have machinery in their build systems to do cargo vendor themselves at the appropriate time, or to just fetch dependencies from the network as if it were a developer build.

(For example, in openSUSE, the Open Build Service can take an existing Cargo.lock - as shipped by librsvg - and vendor the dependencies itself.)

What do you think of librsvg switching to not bundling its Rust dependencies?

2

Hej,

from a distributor perspective it’s still nice to have a release tarball that’s buildable without having to download things other than the actual release tarball. Is it (too) much effort to provide the release tarballs for librsvg? For the Rust apps I maintain running cargo vendor and packing the result in a tarball isn’t really much of a problem (and is only a few lines of SH thanks to meson).

3

I think that’s a good idea.

I don’t think many “end users” are building it from source anyway and if they are then they probably know what to do.

But I personally hate the whole “vendored dependency” approach to begin with so I am very biased on this…

4

I’d say that from a distributors perspective, a distribution should always build everything from source. So as long as there is the possibility to build everything from source and to have all dependencies under manual control, everything should be fine.

5

Asking around, it sounds like this should work for Fedora. I’m not sure if RHEL could handle this, though. We might wind up packaging a re-vendored tarball instead, which would be inconvenient, but not the end of the world…

6

(Replying to several replies at once)

No, it’s not a problem - the autotools setup in librsvg already does the cargo vendor step. Back when librsvg first started including Rust code, we put that in as I think no distros had special tooling to deal with Rust dependencies, and I wanted to make it easy for them to keep shipping librsvg as usual (my assumption was that since they were already shipping Firefox, at least they would have a working Rust compiler).

However…

Does RHEL ship 389-ds or rav1e? Those are two projects I know that don’t vendor their dependencies. In build.opensuse.org we have tooling that takes a Cargo.lock with the resolved dependencies, downloads the sources, and sticks a vendor.tar.xz as part of the SRPM sources.

I guess my question is about, are distros generally equipped to do this sort of thing nowadays, or should librsvg keep vendoring its dependencies. From my viewpoint as a maintainer it would just mean smaller release tarballs (hopefully to be replaced by releasing directly from git tags when GNOME is ready to do that), and less worrying about that part of the autotools setup (it works pretty stably, but you know, less build code = better).

7

@kalev do you have any opinions on this?

I doubt it.

That said, of course we should do what’s most convenient for most distros, not what’s most convenient for one in particular. So if most distros can handle it fine, I guess it’s fine…

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.