On Mon, 14 Sep 2020 10:10:30 -0400
Ben Cotton <bcotton(a)redhat.com> wrote:
Following the general upwards trend in the Rust language's
popularity,
more and more applications and services in fedora are written in Rust.
This includes some CoreOS services, PARSEC, some nice command line
tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of
the GNOME stack.
As an upstream developer for most of those CoreOS projects, I wonder
whether this proposal is going to make it even more complex to
package applications on release branches, due to the network effect of
dependencies.
** ongoing effort: help package maintainers with merging changes
from
rawhide (where appropriate) and creating compat packages (when
necessary) - this is made easier by the strong SemVer compatibility
guarantees of Rust crates
In particular, it sounds like Fedora will try to:
* package most of crates.io libraries, now *one more time per each
branch*
* align all applications to use the same dependency versions
(possibly across release branches?)
Taking one of those projects as an example, Afterburn has (more or less)
monthly releases[0], a bot keeping dependencies fresh[1], and ~200
crates in its full set of transitive dependencies[2] (only a subset of which
relevant for Fedora).
[0]
https://github.com/coreos/afterburn/releases
[1]
https://github.com/coreos/afterburn/issues?q=label%3Adependencies+is%3Acl...
[2]
https://github.com/coreos/afterburn/blob/master/Cargo.lock
Now, these dependencies when packaged have to live with additional
constraints from other applications, which may still be on older
non-semver-compatible versions.
Effectively this means that Fedora downgrades[4] those dependencies
until all other packaged applications converge on a shared version
(which is not guaranteed to happen, depending on relative velocity of
different upstream projects).
[4]
https://src.fedoraproject.org/rpms/rust-afterburn/blob/master/f/afterburn...
The resulting composition has
1) never been tested by upstream CI.
2) may have re-introduced bugs patched by newer library versions
(and seen as fixed by upstream CI).
I'm admittedly not a knowledgeable packager so I don't have a good
alternative proposal to offer, but I wonder whether there is space for a
different path where Fedora:
* doesn't have to re-package all of crates.io (especially not for each
branch).
* doesn't try to align all applications on a single
(major+minor) version of a library crate.
* tries to stay closer to upstream-specified dependencies, handling
those crates relative to the specific application.
* only package library crates whose logic needs to be functionally
patched (affecting multiple applications), and selectively override
only those in manifest/lockfile patches.
* takes a more relaxed approach on having multiple (major+minor)
crate versions co-existing, as long as required by applications.
To be explicit: I'm aware of the cons of vendoring and I'm not asking
for that, but for exploring a model with an "application first" approach
and possibly less toiling on packaging efforts.
Ciao, Luca