On Tue, Jan 21, 2025 at 06:24:26PM -0000, Jan Drögehoff wrote: > Fabio Valentini wrote: > > On Tue, Jan 21, 2025 at 5:13 PM Jan Drögehoff sentrycraft123@xxxxxxxxx wrote: > > > What is a "reasonable" language ecosystem here? > > > Rust sure isn't, I can see at least 6 (0.9, 0.11, 0.12, 0.13, 0.14, 0.15) versions of the rust-hashbrown package in Fedora 41 which all need to be maintained separately and if someone wants to package something that depends on 0.10 then they need to start maintaining that as well. > > Oh, come on, this is a bad example, and you should know it. > > should I? > I've tried packaging rust software many times before and always given up because its a huge task to deal with the whole dependency graph, especially if no one packaged it already. > > With zig I'm explicitly trying to avoid this in fedora, expecting everyone to be willing and capable of such a giant task is unrealistic and discourages others from contributing. > > > 1. There are very few Rust crates for which we need to provide that > > many different versions. > > The only cases are for widely used libraries that *also* frequently > > change API (like hashbrown, nix, or quick-xml). > > Otherwise we would already have ported everything to newer versions > > of those libraries. > > a quick search showed me roughly 25 packages which had multiple versions packaged in fedora > if you have a big hand in all the packages within the ecosystem then its a bit more trivial to make changes across the board but if anyone else wants to package something that requires a dependency either not available in fedora or too new/old then their options are to either ask someone else to create and maintain it for them or do it themselves which then means also packaging every sub-dependency. > You could have a package be owned and maintained by a language specific SIG but this hasn't stopped packages from going unmaintained in the past. What you write here is mostly true for Rust, and it works just fine. We introduced the requirement that all rust-* packages must be co-owned by the SIG. This means that everybody has or can have "a big hand in all the packages within the ecosystem". If the critical threshold of packagers active in the ecosystem is met, then this works quite well. Consider https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html: there are 7 failed rust packages there. Part of the reason is that by not bundling we don't have a long tail of old versions stashed in other projects. It seems likely that Golang needs to adopt vendoring for two reasons: upstream doesn't like meaningful versioning and API stability, and there just aren't enough maintainers interested in keeping it afloat. But it's not correct to try to paint other — more healthy — ecosystems with the same brush. > > 3. Packaging something new that depends on the *one* version missing > > from Fedora repos (0.10) out of that list is a non-problem. > > Because 0.10.0 was "yanked" (unpublished) by the upstream project, > > nothing *can* (realistically) depend on it. > > Fabio > > this was a hypothethical that besides being yanked seems fairly grounded in reality to me. > *If* 0.10 wasn't yanked then its not unlikely that something would have depended on it meaning there would be a 7th package just for this one dependency. Fabio was alluding the the fact that to create this additional version, we need something like 'fedpkg request-repo --exception…' and copy the spec file and edit a few numbers and do 'git push && fedpkg build'. Within a sane ecosystem, only a small number of compat packages are required and this is not too much of a burden. Zbyszek -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
