[CORE-UPDATES] librsvg and rust

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

Core-updates is almost done which means we need to come to a decision
about librsvg and the rust crates.

The problem:
The librsvg tarball includes bundled rust crates. We normally unbundle
bundled sources, and we just so happen to have a) replacement crates for
the bundled ones, b) a method to replace them, and c) a method to build
the package with our packaged crates.
There are multiple cycles between the crates themselves, and between
"traditional" packages (like gtk) and librsvg, traversing the crates.
We (currently) cannot track the dependency cycles between the crates, so
we need to Do Something™.

Option 1:
Track down the ~220 crates which form the dependency graph (of crates)
for librsvg and pin them until the next core-updates cycle. Continue
like with other packages and add newer versions (like cmake or meson) as
packages need them.¹

Option 2:
Use the bundled crates and treat it as just part of the librsvg source
code.²

Option 2b:
Use the bundled crates for now to finish with core-updates-frozen and
revisit this immediately on core-updates (not frozen).

Notes:
Bug 51845 is so far where it's been discussed a bit, but it seems more
relevant for guix-devel.

Ludo has made a nice first patch at treating rust packages in inputs as
cargo-inputs (and native-inputs as cargo-development-inputs), allowing
us to piecemeal change the rust crates. This doesn't directly help with
our librsvg problem, but will help us track dependencies across rust
packages.

Thoughts?

I'm currently leaning option 2b, it'll get us past this hurdle for
core-updates-frozen and let us make changes to the crates as we work to
integrate them more fully into Guix.


¹ If there are any security problems in any of the crates we'd be
grafting librsvg itself, not the individual crates (this is due to how
crates are used).

² (We are not Debian) This is what Debian does.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]