On Thu, Sep 24, 2020 at 11:51 AM Luca BRUNO <lucab@xxxxxxxxxxxxx> wrote: > > 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. Hi Luca, Thanks for your detailed feedback, I've responded to your questions below. > 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. I hope that this won't be the case, and I'll also invest time to prevent this outcome, if at all possible. > > ** 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* No. This is definitely out of scope. I don't see a reason to package things that nothing in fedora depends on, for example. crates.io ships 47,039 crates today, but only a fraction of those are actually packaged and / or required for fedora (today, 1225). > * align all applications to use the same dependency versions > (possibly across release branches?) This is also out of scope, because I don't think it would be possible. The proposal text should make it pretty clear that release branches should mostly follow rawhide in terms of source-only package updates, and - if necessary - compat package creations. Binary packages already follow the Update Policy, so nothing changes for those. Essentially, all I want to change is that package dependencies won't be broken as freely by pushing semver-incompatible version updates in rawhide, at least not without creating the necessary compat packages for older versions. My hope is that this will actually make it *easier* to package Rust applications on both rawhide *and* on 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). I hope that dependency downgrades will happen less often, not more often. I don't see a need for all dependent packages to converge on a shared version, either, since I don't share the disdain for compat packages some others do :D - so long as they're used in moderation, and removed when no longer needed. > [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 agree, this is not a good situation, and one that I hope this proposal and the resulting changes will remedy, instead of making it worse. > 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). There's no need to re-package things for each branch. Most changes can be "git merge"d. This is how package updates are handled in fedora, Rust has only been a weird special case in this regard ... > * doesn't try to align all applications on a single > (major+minor) version of a library crate. As explained above, this isn't the intention of this proposal. > * tries to stay closer to upstream-specified dependencies, handling > those crates relative to the specific application. I hope that this is actually the outcome of the proposed change. > * only package library crates whose logic needs to be functionally > patched (affecting multiple applications), and selectively override > only those in manifest/lockfile patches. This is actually what I'm aiming for. If there are no *code changes* necessary when updating a dependency, then I don't see a reason to not do that, and submit the change to the upstream project as well. For updated where code changes are necessary, that's not always feasible without upstream doing that first, so in this case, compat packages for the old library version come in. > * takes a more relaxed approach on having multiple (major+minor) > crate versions co-existing, as long as required by applications. This is actually what I'm aiming for :) > 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. I agree. I ship two Rust applications as fedora packages (admittedly, with smaller dependency trees), but it's still painful to do for release branches. Are your dependencies all maintained by the Rust SIG? Then I'm aiming for a future where you don't have to care about them at all when submitting updates for your applications, because all your dependencies will already be up-to-date, and you'll only have to care about *new* dependencies. I hope that I was able to explain some things better than in the initial proposal. Thanks, Fabio _______________________________________________ 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
