Re: How to build Rust packages

[Efraim Flashner]

On Thu, Dec 05, 2024 at 11:13:07AM +0100, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > I still have a copy of the code on my machine but unfortunately it no
> > longer builds due to the constant churn of rust packages.
> >
> > One thing I remember explicitly about it was that building end packages
> > was faster than the current method, and that was before taking into
> > account reusing build artifacts.
> >
> > https://notabug.org/maximed/cargoless-rust-experiments
> 
> Neat.
> 
> > Another idea which I'm not in love with is what Debian does. They grab
> > all of the sources into one build environment and then build everything.
> > It simplifies the dependency management of the sources but for us it
> > would make it so that we can't touch anything in rust without causing a
> > full rebuild of everything.
> 
> I believe this is also what Nixpkgs does, as discussed in this thread:
> 
>   https://toot.aquilenet.fr/@civodul/113532478383900515

I'm pretty sure they parse the Cargo.lock file and download the crates
at build time.

> I’m not a fan either.  But I think one of the main criteria here should
> be long-term maintainability, which is influenced by internal design
> issues and by how we design our relation with the external packaging
> tool.
> 
> By internal issues I mean things like #:cargo-inputs instead of regular
> inputs, which makes the whole thing hard to maintain and causes
> friction.  (See <https://issues.guix.gnu.org/53127>.)
> 
> As for the relation with Cargo and crates.io, the question is should we
> map packages one-to-one?  Is it worth it?  If the answer is yes, do we
> have the tools to maintain it in the long run.

As it stands now the package name is effectively prepending 'rust-' and
switching any underscores to dashes.  Most of the actual packaging work
is making sure the cargo-inputs from patches correctly match the
versions in Cargo.toml, checking the metadata (license, home-page,
synopsis/description), and seeing if any code needs to be removed (such
as from *-sys packages).  If there are any "real" packages then they
normally don't have the rust- prefix.

I don't want to go and parse Cargo.lock, automagically generate packages
based on that, and then download those as cargo-inputs for packages. Not
only does that potentially pull in old versions of libraries which may
have necessary updates or patches, it doesn't check them for license
data or vendored C libraries.

I also don't want to keep a collection of "difficult" crates that need a
human touch and have everything else be autogenerated at package build
time.

I am jealous of the cran updater and all the work Rekado has put into
making it work well, and I know I need to actually fix a bunch of stuff
with the crates.  An updater and also the etc/committer.scm file.  There
are too many crates to actually package them all, so that wouldn't be
something workable to automatically package all of them.

I have a script that goes through the crates and lists how many
dependencies there are per file, and I have used it in the past to
remove unused crates.  I have also come back and added them back in when
something else needed them.

My workflow is I work on 20-50 crates at once, and when they all build
correctly I then break them into the appropriate number of commits.

I'm not sure where to go from here.  I don't even remember if the
antioxidant build system correctly shows the dependency path between
crates, which IMO is one of the big things missing now.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature