Rust October 2024

rust@lists.fedoraproject.org

2 participants
2 discussions

Orphaning eza (rust-eza - maintained fork of exa)
by Fabio Valentini 31 Oct '24

31 Oct '24

Hi all, TL;DR: I am planning to orphan rust-eza later today. Be warned - it's a lot of work to keep up with upstream (~1 release per week), keeping it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and there are license shenanigans afoot since the v0.20.0 release (package is currently at v0.19.3). Given that I don't even use eza myself and just packaged it because it was on some people's wishlist as the maintained fork of exa, I really cannot justify the ongoing cost of maintaining this package to myself. Fabio --- Longer version: The upstream project releases new versions at a very fast pace (almost exactly one release per week on average this year). They also have set up GitHub's dependabot to automatically and eagerly bump all their Rust dependencies to the latest versions - most of which are not technically necessary. Additionally, they often add new dependencies, which is an additional maintenance burden on top of needing to keep up with their eager dependency bumping. The package should be in relatively good shape, except that it is slightly outdated. I have just yesterday updated it to the latest version that does not introduce new dependencies that aren't packaged yet for Fedora (0.19.3, released on Sep 12). At the time of writing, the latest release is 0.20.6 (released today, Oct 31) - but more info on that below. The package is available in all branches of Fedora, in EPEL 9, and in EPEL 8. All branches are equivalent, with the exception of EPEL 8, which needs special handling because the Rust packaging toolchain there is ancient (from RHEL 8), while the EPEL 9 toolchain matches the one in Fedora. The package was branched for EPEL 8 per a user's request, so dropping it (or letting it become outdated) just a few months after it was added to EPEL 8 would not be nice IMO. It might be of note that the project was relicenced from MIT to EUPL-1.2 without much fanfare as of the 0.20.0 release, in this mess-of-a-PR: https://github.com/eza-community/eza/pull/1155 - I'm not a lawyer, but the maintainer unilaterally slapping a different license onto a project that's been around since 2017 in some form without asking other contributors (or the original author of exa) doesn't pass the smell test for me.

1 0

Question about modifying dependency versions
by Orion Poplawski 30 Oct '24

30 Oct '24

I'm working on building clamav for EPEL10. The versions of various rust dependencies are different in EPEL10 than EPEL8/9. We generally try to maintain identical spec files across the EPEL releases (and Fedora <=41 at this point). Would it be acceptable to do the following in the spec file: sed -i -e '/^base64 *=/s/= .*/= "0.*"/' Cargo.toml sed -i -e '/^bindgen *=/s/= .*/= "0.*"/' Cargo.toml sed -i -e '/^cbindgen .*=/s/= *".*"/= "0.*"/' Cargo.toml sed -i -e '/^image .*=/s/= *".*"/= "0.*"/' Cargo.toml sed -i -e '/^onenote_parser *=/s/= *.*/= "0.*"/' Cargo.toml to allow for using whatever is the latest version of the dep in each release? Or is there some other preferred way to handle this situation? Thanks, Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

Rust October 2024