[CORE-UPDATES] librsvg and rust

[CORE-UPDATES] librsvg and rust

[Efraim Flashner]

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

Re: [CORE-UPDATES] librsvg and rust

[Ludovic Courtès]

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.

Thanks for keeping the ball rolling!

Ludo’.

[bug#51845] [CORE-UPDATES] librsvg and rust

[Ricardo Wurmus]

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.

-- 
Ricardo

Re: [CORE-UPDATES] librsvg and rust

[Kaelyn]

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

Re: [bug#51845] [CORE-UPDATES] librsvg and rust

[Efraim Flashner]

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

On Wed, Dec 08, 2021 at 02:36:11PM +0000, Ricardo Wurmus 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.

Patches pushed to core-updates-frozen. I added a TODO to fix the
situation.

Thanks for the input everyone.

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