On Mon, Jun 19, 2023 at 5:45 PM David Michael <fedora.dm0(a)gmail.com> wrote:
Hi,
Hi David!
I tried the Firecracker 1.4 branch which depends on new crates that
will need to be added to Fedora. Should I wait for the release before
adding crates, or can they be packaged early while nothing depends on
them? (I don't know when the actual release will happen.) Here are
specific crate package changes:
A couple things depend on bindgen-0.65 now (and 0.66.1 is available),
although they have workarounds, e.g. ExclusiveArch for pregenerated
files. This update isn't necessary yet, but it would be nice to have.
Updating bindgen is sadly always a bit of a chore, since the easy way
(creating a "compat" package for the old version, updating the "main"
package to the new version) does not really work here. I tried it with
bindgen v0.59, and it led to all sorts of weird and hard-to-debug
problems with applications that started (transitively) depending on
both bindgen v0.59 and v0.64 via different dependencies ... and I
would like to avoid this situation in the future.
So this means that for every bindgen / bindgen-cli update, *all*
crates that use it need to be patched and / or adapted for API changes
to avoid this kind of collisions (which means a lot of work, and it's
the reason why bindgen / bindgen-cli currently only happen when
absolutely necessary).
Both bindgen-0.65 and firecracker-1.4 depend on bitflags-2, so that
update is required. The new bitflags depends on the unpackaged
zerocopy and zerocopy-derive for tests. (They have license file
issues that are fixed in Git for the upcoming 0.7.0 version but not in
stable releases on crates.io, and zerocopy-derive tests have a dep
loop on zerocopy.) Fabio, you own bitflags-1, do you want to own the
new API package and its deps, or should I submit their package review
requests?
Interesting, this is the first crate that I know of that moved to bitflags v2.
Well, this would mean we'd update the "rust-bitflags" package to v2,
and add a new "rust-bitflags1" package for version from the v1 branch.
Since I'm already the owner of the package, I'll handle that. Just
make sure to comment on the bug so I don't forget:
https://bugzilla.redhat.com/show_bug.cgi?id=2177627
Regarding the zerocopy / zerocopy-derive dependencies:
Rather than package versions with known problems (like license
issues), I'd disable tests in the package for bitflags v2 for now.
Once these problems are resolved in released versions, this can be revisited.
I know of several other Rust crates in Fedora where we have optional
dependencies on zerocopy disabled right now, having
zerocopy/zerocopy-derive in Fedora would allow us to enable those
features again (and to enable the test suite in bitflags v2).
The firecracker-1.4 branch relies on an AWS crypto library for
VirtIO
RNG support. The main aws-lc-rs crate depends on aws-lc-sys and
mirai-annotations which will need to be added. The aws-lc library is
a separate C++ project which is bundled into the aws-lc-sys crate.[0]
Since nothing else in Fedora is using the aws-lc C++ library, my
preference would be to leave it as an implementation detail in the
crate and not unbundle it or worry about dynamic linking. Is that
acceptable for the package?
It might be, or it might not be. If I remember correctly, no new SSL /
TLS implementations should be packaged for Fedora without at least
requesting comments from the Red Hat crypto people (but I cannot find
this in the Guidelines right now, so I might be mistaken). The only
thing I *can* find right now is the requirement that SSL / TLS
implementations MUST adhere to system-wide crypto policy [0], which
this AWS project would likely not satisfy. It would be good to ask
about this on the devel and/or packaging mailing list,
Alternatively, aws-lc-rs claims "This library strives to be
API-compatible with the popular Rust library named ring.", and the
"ring" crate is already available in Fedora ... so you might be able
to side-step the paragraph above by replacing the dependency on
"aws-lc-rs" with a dependency on "ring". (I'm not mentioning the
fact
that when the "ring" crate was packaged, the things in the paragraph
above were ignored.) Also note that the "ring" crate is basically
abandoned (which might be the reason for why Amazon developed a
drop-in replacement?), and both upstream projects (RusTLS / Quinn /
Parsec / etc.) and downstream packagers (me) are actively trying to
*drop* dependencies on "ring" (and, if possible, use OpenSSL instead).
Fabio
[0]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_system_crypto...