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.