18.03.2023 00:40, Gurchetan Singh пишет:
[[big snip]]
Okay, I think the next steps would actually be code so you can see our vision.
I have few questions that will help with my RFC:
1) Packaging -- before or after?
gfxstream does not have a package in upstream Portage or Debian (though there are downstream implementations). Is it sufficient to have a versioned
release (i.e, Git tag) without the package before the change can be merged into QEMU?
Is packaging required before merging into QEMU?
2) Optional Rust dependencies
To achieve seamless Wayland windowing with the same implementation as crosvm, we'll need optional Rust dependencies. There actually has been interest
in making Rust a non-optional dependency:
https://wiki.qemu.org/RustInQemu <https://wiki.qemu.org/RustInQemu>
https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg04589.html
<https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg04589.html>
I actually only want Rust as an optional dependency on Linux, Windows, and MacOS -- where Rust support is quite good. Is there any problem with using
Rust library with a C API from QEMU?
3) Rust "Build-Depends" in Debian
This is mostly a question to Debian packagers (CC: mjt@)
Any Rust package would likely depend on 10-30 additional packages (that's just
the way Rust works), but they are all in Debian stable right now.
https://packages.debian.org/stable/rust/
<https://packages.debian.org/stable/rust/>
I noticed when enabling virgl, there were complaints about a ton of UI
libraries being pulled in.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813658
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813658>
That necessitated the creation of the `qemu-system-gui` package for people who don't need a UI. I want to make gfxstream a Suggested Package in
qemu-system-gui, but that would potentially pull in 10-30 additional Rust build dependencies I mentioned.
Would the 10-30 Rust Build dependencies be problematic? I think QEMU already
has hundreds right now.
There's no reason to worry about *build*-time dependencies.
There's also no big reason to worry about runtime dependencies, and to worry
about
Suggests vs Recommends, etc, - this all can be adjusted when needed, packages
can
be spilt further, etc, - it is normal practice.
/mjt
