On Mon, 14 Sep 2020 10:10:30 -0400 Ben Cotton <bcotton@xxxxxxxxxx> 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%3Aclosed [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-fix-metadata.diff 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
