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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted