Spec URL: https://raw.githubusercontent.com/elmarco/ironrdp-fedora/refs/heads/master/rust-rstest0.25/rust-rstest0.25.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/elmarco/qemu-rdp/srpm-builds/09249357/rust-rstest0.25-0.25.0-1.src.rpm Description: Rust fixture based test framework. It use procedural macro to implement fixtures and table based tests. Fedora Account System Username: elmarco - Testing is disabled (it needs earlier version and there is an issue with the crate: "error[E0432]: unresolved import `rstest_test`". I didn't investigate further)
rstest v0.25 is the latest version, and the latest version is supposed to be shipped by the un-suffixed source package. That said, it looks like you no longer need it (for now)?
Given how often rstest crate is released, and the number of dependent packages, I wonder if having an un-suffixed source package is helping or crating more trouble and overhead than necessary.
Given that the number of dependent packages has been growing, yes, it might make sense to start providing compat packages to ease the upgrade path and maintenance for dependent packages. However, having *one* un-suffixed package is *MANDATORY*, and it's usual practice for that one to have the *latest* version.
Why is it mandatory to have unversionned package name? afaik, this doesn't apply to C libraries for example, where libfooX is fairly common. This would avoid the burden to update all the up to date dependents packages every time upstream bump...
> Why is it mandatory to have unversionned package name? Because ... it's a rule? https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple > This would avoid the burden to update all the up to date dependents packages every time upstream bump... The same is achieved by the current approach though? I don't understand the problem you're trying to solve here.
(In reply to Fabio Valentini from comment #5) > > Why is it mandatory to have unversionned package name? > > Because ... it's a rule? It's not a strict rule: "One package SHOULD use the base name" > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple > > > This would avoid the burden to update all the up to date dependents packages every time upstream bump... > > The same is achieved by the current approach though? How so? If "rust-foo" depends on "rust-rstest" == 0.25 and we bump "rust-rstest", then "rust-foo" is broken. Thus we need to update all reverse-deps to use the branched version whenever a new version of rstest is released. Or am I missing something? > I don't understand the problem you're trying to solve here. Not having to update all the reverse deps whenever a package bump its major version.
Whether the source package names are "rust-rstest0.25" and "rust-rstest0.24" or "rust-rstest0.24" and "rust-rstest" (for 0.25) doesn't change that there's now two packages. In fact, having the latest one be "unsuffixed" *reduces* the number of necessary packages (because new versions don't necessarily need a new source package!) ... > Thus we need to update all reverse-deps to use the branched version whenever a new version of rstest is released. Or am I missing something? We already handle cases like that with compat packages. In fact, to unblock things, I've prepared the update to rstest v0.26 and added "compat" packages for the current version (rstest 0.23). No broken dependencies involved ...
I don't see how the rust-rstest0.23 package will replace rust-rstest == 0.23 seamlessly: https://src.fedoraproject.org/rpms/rust-rstest0.23/blob/rawhide/f/rust-rstest0.23.spec How does it work?
All dependencies on Rust crates are via virtual Provides like `Requires: (crate(rstest) >= 0.23 with crate(rstest) < 0.24)`. This is currently satisfied by the rust-rstest-devel package (which `Provides: crate(rstest) = 0.23.0`), and will later be satisfied by the rust-rstest0.23-devel package instead after the update. There are no dependencies on exact package names, just on these virtual Provides, so the migration is transparent and seamless.
ok, thanks the clarification!
thanks, dropping this bz now that 0.26 is available.