Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 935726 - cargo.eclass: cannot patch crates (e.g. for app-emulation/virtiofsd)
Summary: cargo.eclass: cannot patch crates (e.g. for app-emulation/virtiofsd)
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Rust Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-08 02:43 UTC by Huy Logan
Modified: 2024-12-03 09:28 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
python wrapper for virtiofsd (vfsd.py,1.28 KB, text/x-python)
2024-07-08 02:43 UTC, Huy Logan
Details
sample patch that has to be applied manually (virtiofsd.patch.manual,4.37 KB, patch)
2024-07-08 02:44 UTC, Huy Logan
Details | Diff
Sample systemd service file for exporting /mnt dirs (vfsd@.service,334 bytes, text/x-dbus-service)
2024-07-08 02:48 UTC, Huy Logan
Details
Sample systemd service file for exporting /mnt dirs that actually works (vfsd@.service,157 bytes, text/x-dbus-service)
2024-07-08 02:51 UTC, Huy Logan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Huy Logan 2024-07-08 02:43:49 UTC
Created attachment 897308 [details]
python wrapper for virtiofsd

Gentoo has some rust ebuilds. Rust ebuilds that use cargo are built offline. The crates are downloaded and are placed in the workdir at the same level as the source directory, in cargo_home/gentoo. 

It is not possible to apply patches to the rust crates. Also the creating a patch file that would change a number of crates is cumbersome because if the small value changes you might be patch a few src/lib.rs files.

Anyhow here is a sample problem. 
app-emulation/virtiofsd is a rust ebuild.
I have a wrapper for this that creates its own listener on a unix socket for use with qemu so that I can have a socket that multiple instances of qemu can attach to and each one runs a separate application. It might be wrong but gentoo should allow me to do this. This is the whole point of gentoo. 

Here is the python wrapper and attached is a patch that would make this wrapper work. Each time the ebuild changes I have to manually edit the patch based on what versions of crates are there and apply this manually in to work directory. It is too cumbersome and as has been mentioned due to the versioning of the directory names of the crates a simple script by adding a step to the ebuild will not work.
Comment 1 Huy Logan 2024-07-08 02:44:41 UTC
Created attachment 897309 [details, diff]
sample patch that has to be applied manually
Comment 2 Huy Logan 2024-07-08 02:48:17 UTC
Created attachment 897310 [details]
Sample systemd service file for exporting /mnt dirs
Comment 3 Huy Logan 2024-07-08 02:51:15 UTC
Created attachment 897311 [details]
Sample systemd service file for exporting /mnt dirs that actually works
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-07-08 02:51:46 UTC Comment hidden (obsolete)
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-07-08 02:51:50 UTC
In general, especially for complex topics, please consider using a real email so that discussion can be had over an extended period rather than into a blackhole.

Anyway, yeah, it's a hard problem.
Comment 6 matoro archtester 2024-07-08 18:45:33 UTC
Is this really something that is the responsibility of the Gentoo Rust team to provide when upstream is not friendly to the idea?  If they want to enforce that crates will not be modified, won't this just be an arms-race without cooperation?
Comment 7 Morgan Chattel 2024-07-08 23:51:36 UTC
I don't think that upstream really care. It is the cargo/crate system that is the issue here in my opinion. At present you can quite easily patch the source for the rust package that contains the main.rs.

The only think that cargo is forcing you do to is have bloated binaries because in the libc world each crate would probably be an .so (shared object) (if you are doing things dynamically).

The same issue probably exists in Npm. Let's have a look there. Any recent issues with some basic whatever they call their packages being subverted? What about log4j in the java world - shouldn't this have been able to have been patched out.

I personally don't think that there is an issue with anyone patching your sources provided you abide by the terms of the license. 

However, at present what you have is only the ability to patch the source that contains the package name. You can easily change crates in the .toml file via a patch. That is currently supported.
Comment 8 Michal Prívozník 2024-07-09 07:52:26 UTC
I tend to agree with Morgan here. I don't think there's anything virtiofsd specific about this issue. 

Out of curiosity, Huy, why don't you let libvirt run virtiofsd for you?
https://libvirt.org/kbase/virtiofs.html