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
On Wed, Oct 30, 2024 at 2:58 AM Orion Poplawski via Rust rust@lists.fedoraproject.org wrote:
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:
The packages in EPEL 10 and EPEL 9 should be exactly the same, with only two exceptions:
- packages might be in epel9 but not yet in epel10 - packages cannot be updated in epel9 because RHEL 9 ships a Rust compiler that is too old
What you're seeing is probably that some *compat* packages are missing from epel10 compared to Fedora or EPEL 9. And that is intentional - we're trying to limit the number of compat packages that we need to branch, and by extension, so we can also drop them from Fedora too.
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?
No :cry: please don't do that. It's very likely that you'll just get hard to debug build failures that way, and things might work on Fedora but not on EPEL 9 one day, but be the other way round the next day. It's also really hard to tell for other packages (i.e. me, maintainer of most of these crates) if your project is actually going to be compatible or not with a new major version without doing a test build. If the dependency has a restricted version range, I *know* that some action is required, without needing to dig into it. Projects specify dependency version restrictions *on purpose*, just dropping them will cause problems due to API changes between major versions of those dependencies.
Or is there some other preferred way to handle this situation?
It would be great if you could reduce the number of compat packages that you need, that should obsolete the need for importing them to EPEL 10 *and* make the package more similar between Fedora and EPEL branches.
In this case:
- base64: versions are mostly API compatible, you should be able to replace "^0.21" with "^0.22" or even ">=0.21,<0.23" if you want to say that the package is compatible with both versions - bindgen: Fedora, EPEL 9, and EPEL 10 all ship the same version that clamav depends on (^0.69), I don't see a problem - cbindgen: ditto, Fedora and EPEL branches all ship both cbindgen 0.26 and 0.27, no problem here - image: all Fedora and EPEL branches ship image 0.25, which is what clamav depends on, no problem here - onenote_parser: you control this one yourself
Fabio
-
Fabio Valentini -
Orion Poplawski