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.
Created attachment 897309 [details, diff] sample patch that has to be applied manually
Created attachment 897310 [details] Sample systemd service file for exporting /mnt dirs
Created attachment 897311 [details] Sample systemd service file for exporting /mnt dirs that actually works
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.
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?
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.
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
