[bug#66953] Working towards rust-rbw update

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

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

On Sun, Nov 05, 2023 at 05:25:32PM +0100, VÖRÖSKŐI András wrote:
> 
> Hi,
> 
> I have a couple of questions regarding this one:
> 
> 1. I did not dare to update rust-libc because `guix refresh` shows a lot of reverse
> dependencies and I have no idea what is the common way of mass rebuilding those.
> 2. Because of this I had to edit rust-cpufeatures Cargo.toml to use the already
> package rust-libc.

What I do is I update the crates as needed, and then I'll see if it
something that can actually be applied to the master branch or if it
needs to go to the rust-team branch.  Generally, if changing a rust
crate involves rebuilding librsvg or python-cryptography then it needs
to go to the rust-team branch.

If there's only one or two patches which cause those packages to be
rebuilt then I'll see if it's possible to not change them and still make
whatever change I'm trying to do.

> 3. Doing so means we have to use `substitute*` every time we use the vendored
> rust-cpufeatures. I am not sure if this is acceptable or not.
> 
> As far as I can tell rust libraries tend to pin patchver in Cargo.toml, but packaging
> every patchver seems to be unsustainable to me. But this way the only option is
> rewriting the Cargo.toml files everywhere, isn't it?

If you put the substitute* in a snippet then the change will be brought
forward to all the packages which use that crate, and then you won't
need to change each crate individually.

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