On Mon, Dec 06, 2021 at 01:17:47PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> I had completely overlooked these patches, oops!
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > librsvg is an input for emacs, gtk+@2 and gtk+@3. With the rust inputs
> > this leads to (unknown) rust libraries causing the rebuild of over 3000
> > packages on core-updates-frozen. Rather than hunt them down I tracked
> > down the packages which would have many rebuilds and added a copy of
> > librsvg for them to use.
> 
> [...]
> 
> > I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates and
> > for the other 101 packages we continue to use our current version, where
> > we replace all of the bundled crates with our own copies, which get
> > updated more often than librsvg does.
> >
> > With our current rust tooling I don't think it'd be that easy to find
> > the ~226 crates that librsvg depends on, and it wouldn't be great to
> > lock them due to librsvg being an input for gtk2/3.
> 
> Yes, that’s a problem, though Liliana is right that bundling isn’t great
> either.
> 
> I’m annoyed by this whole librsvg situation.  On non-x86_64, we now
> depend on librsvg 2.40, the old C version, and guess what, it just
> works.  That has me tempted to stick with 2.40 all along because these
> Rust problems don’t seem to have a pleasant, or even an easy solution.
> 
> Now, using the proposed ‘librsvg-bootstrap’ in GTK+ looks like a lesser
> evil.
> 
> Thoughts?

Unbundling the rust crates is the right option, but not the easy option.
With the assumption that rust-libc-0.2 is in the graph for librsvg, we
add another copy named rust-libc-0.2.101 (the current version) and a
comment that it only gets adjusted on core-updates or that it causes
XXXX package rebuilds.

On a small tangent, the work I do sometimes to try to actually have a
dependency graph with the crates would only make these easier to find,
not actually address the issue here.

I'm not sure if it'd be better to mostly copy the packages with a new
name and keep the cargo-inputs or to actually adjust the
cargo-inputs->inputs and cargo-development-inputs->native-inputs  so we
get the dependency graph from rust-libc-0.2.101 to librsvg. I'd like to
make the change but if we don't get the others changed then we
effectively really have two sets of rust crates.

If we have both cargo-inputs and inputs then the cargo-build-system
doesn't have issues with using either type with later packages, so that
might be the best option for 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