-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
This email attempts to answer some frequently asked questions about
Rust SIG packaging of crates. For those who don't know what a "crate"
is: it is the name for a collection of functionality in Rust, similar
to libraries (C/C++), modules (Python/Perl/PHP), gems (Ruby), etc.
In Fedora, we package each crate separately and then use them as
BuildRequires to build the binaries (applications/utilities). The
crates are built and linked statically to each other, so they are not
present on user’s systems. The resulting binary build only has non-Rust
dependencies at runtime (standard library, C/C++ libraries, etc.).
Many folks ask the Rust SIG many variations of the same questions, so
we decided to provide a common set of questions and answers for that.
## Q: Why do you package those small bits separately than just
vendoring (bundling) them?
You (hopefully) all know that bundling is bad. There are many reasons
for this ranging from security to maintainability to licensing
compliance. This problem does not get better when your dependency
graphs get very wide (as they do for languages like Rust, Go, Nodejs,
etc.).
When we package something, we:
1. Check licensing
We make sure that acceptable (for Fedora) open source licenses are
used, license files exist and contain proper license texts, ensure
compatibility of the licenses in resulting binaries, keep track of
changes and properly announcing any license changes to ensure that
distribution of Fedora stays legal.
2. Build the software and run the tests
We have found quite amount of
* Architecture-related bugs
* 32bit vs 64bit
* big endian vs little endian
* Dependency information not being correct
* Breakages or issues in new versions of the Rust compiler
And many others.
Of course it would be nice if upstreams have extensive test coverage on
all distros and platforms, but this is unfortunately not the case. Much
of it has to do with the limitations of CI/CD services that are in
common use (such as Travis CI, Azure DevOps, GitHub Actions, etc.). For
example, Travis CI does not offer Fedora so people often only test
things with some old version of Ubuntu LTS with a hodgepodge of tools
and libraries with varying degrees of age. Unfortunately, this is
simply not something the Rust SIG is capable of fixing. But when we do
package it ourselves in Fedora, we catch these things and send fixes
upstream to ensure that everyone benefits from the work we *can* do to
make things better.
3. Integrate it with the rest of the distribution
For example, many crates that are bindings to the C libraries tend to
bundle C libraries instead of linking with system-provided shared
libraries. Sometimes they will use the system-provided shared libraries
only under specific circumstances. We patch them to always use system
libraries and run the test suites to ensure that they actually work.
This allows us to leverage the work that has been done to maintain
system libraries to keep Rust software in good shape.
As an example, libgit2-sys used to use system libgit2 only if some
environment variable was set, we had patch from day 0 to change that
condition and use system libgit2. As libgit2 is a library that tends to
need security fixes often, doing this allows us to avoid having to
rebuild any Rust applications that link to libgit2 whenever we fix
libgit2 and roll out fixes *very* quickly.
Now imagine that you'd need to apply all those fixes to each
application which depends on libgit2-sys. Today, we have following in
Fedora:
* bat
* cargo-c
* exa
* pretty-git-prompt
* silver
* starship
Even though they are statically linked (in terms of crates), they use
the standardized way of building packages in Fedora and it is possible
to know which versions of which component was used to build them so
that we can make adjustments as needed.
## Q: You patch crates and that harms the reputations of the upstream
projects!
Firstly, it's important to recognize that patching software in itself
is not inherently bad. There are many reasons to do this, and it's a
matter of having the right discipline to figure out what the right
thing to do is.
Secondly, when we *do* patch crates, we always send patches to the
upstream projects and most of them are accepted. There are a few
patches which have been rejected or not accepted. The most common
reason for this is that upstream is dead, plain and simple.
Finally, since we try to keep only the latest version of a crate in
Fedora, the bulk of our patching is oriented around porting crates /
applications to latest version of their dependencies, which is
generally appreciated by upstream (unless they have some unusual
compatibility promises).
So we are often doing a good service to the upstream projects
developing and maintaining those crates by sharing a bit of that burden
and helping them move forward!
## Q: Why not to have mirror of crates.io in Fedora?
I would ask same for every ecosystem,
