Re: [CORE-UPDATES] librsvg and rust

[Kaelyn <kaelyn.alexi@protonmail.com>]

On Wednesday, December 8th, 2021 at 6:36 AM, Ricardo Wurmus <rekado@elephly.net> wrote:

> Ludovic Courtès ludo@gnu.org writes:
>
> > Hello!
> >
> > For the record, this is a followup to Efraim’s proposal in
> >
> > https://issues.guix.gnu.org/51845.
> >
> > Efraim Flashner efraim@flashner.co.il skribis:
> >
> > > 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.¹
> >
> > The advantage of this approach is that we could do it incrementally: we
> >
> > could merge ‘core-updates-frozen’ today and just add pinned variants of
> >
> > these 200+ crates as needed as time passes. The downside is that it’s a
> >
> > lot of crates to take care of, and we might still accidentally overlook
> >
> > seemingly innocuous crate upgrades that end up causing major rebuilds.
> >
> > > 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).
> >
> > This option will involved a rebuild on x86_64, but the advantage is that
> >
> > we’ll be safe going forward: we won’t accidentally cause world rebuilds
> >
> > just because an obscure crate somewhere has been upgraded.
> >
> > [...]
> >
> > > 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.
> >
> > Same here; it’s not ideal, but it seems like the most reasonable
> >
> > short-term option.
> >
> > If there are no objections, I’d suggest that you go ahead with this
> >
> > plan.
>
> I agree that 2b is the most sensible option in our current situation.

As a developer and new-ish Guix user (and not someone familiar with rust), I am also in favor of 2b. Dealing with 200+ dependencies takes time, and core-updates-frozen has been on the cusp of merging for some time now.

I'd like to see c-u-f merged back into master sooner, as master lacks support for newer hardware while also getting regular package updates that are only periodically merged to core-updates-frozen. Even before the c-u-f sprint last month where I switched all of my systems to c-u-f, I had one system that was first a frankensteined master before finally managing to switch it to c-u-f, to pick up a newer mesa that wasn't unusably buggy on a Radeon RX 6700 XT.

Cheers,
Kaelyn

P.S. Regarding switching my systems, the only issue I've run into that hasn't been fixed is that tigervnc only recently added support for building against xorg-server 21.1.1, and the current tigervnc release (1.12.0) was released before that support landed. (I have a standalone package definition for building a recent git commit.)
>
> ------------------------------------------------------------------------
>
> Ricardo