Bug 2377151 (rust-rstest0.25)

Summary: Review Request: rust-rstest0.25 - Rust fixture based test framework
Product: [Fedora] Fedora Reporter: Marc-Andre Lureau <marcandre.lureau>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: decathorpe, package-review
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-07-30 14:41:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2377098, 2377134    
Bug Blocks: 2343680    

Description Marc-Andre Lureau 2025-07-08 12:29:42 UTC
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)

Comment 1 Fabio Valentini 2025-07-24 13:55:47 UTC
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)?

Comment 2 Marc-Andre Lureau 2025-07-28 07:01:15 UTC
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.

Comment 3 Fabio Valentini 2025-07-29 20:26:50 UTC
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.

Comment 4 Marc-Andre Lureau 2025-07-30 06:53:18 UTC
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...

Comment 5 Fabio Valentini 2025-07-30 10:36:51 UTC
> 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.

Comment 6 Marc-Andre Lureau 2025-07-30 10:58:16 UTC
(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.

Comment 7 Fabio Valentini 2025-07-30 12:35:03 UTC
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 ...

Comment 8 Marc-Andre Lureau 2025-07-30 12:47:36 UTC
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?

Comment 9 Fabio Valentini 2025-07-30 13:23:46 UTC
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.

Comment 10 Marc-Andre Lureau 2025-07-30 13:55:50 UTC
ok, thanks the clarification!

Comment 11 Marc-Andre Lureau 2025-07-30 14:41:17 UTC
thanks, dropping this bz now that 0.26 is available.