packaging-committee

#1124 clarifications for Rust Naming and Versioning guidelines
Merged by tibbs. Opened by decathorpe.
Unknown source master

Download 1124.patch

This PR introduces clarifications for Naming and Versioning guidelines for Rust packages. I tried to address some questions that have come up a few times on the #fedora-rust IRC channel.

Naming:

Document that application-only crates may / need to diverge from the standard rust-$crate naming scheme:

  • application-only crates published on crates.io MAY drop rust- prefix
  • application-only crates not published on crates.io MUST drop rust- prefix to prevent naming collisions with the crates.io namespace

Versioning:

Document that some features of SemVer as used in the cargo ecosystem must be dropped when packaging crates as RPMs for Fedora (i.e. +x.y.z build information encoded in some published crates's version field MUST be dropped, as it pollutes generated Provides and might cause dependency resolution issues).

I tried to apply SemBr to my changes, but as those semantic breaks are quite subjective, there might be room for improvement.
I'd also appreciate it if an English native speaker could review my grammar. :)

I'm also not sure if it's OK to link to an existing package as an example of how to do something - but documenting the thing in question without linking to a working example would be awkward.

We do link into the package source repositories on occasion and it has been problematic. The links will break if a package gets retired, or the master branch gets changed to main, or whatever. I've recently fixed up a number of these.

It's often more future-proof to just make copies of relevant files in the examples directory and then include the files directly in the guidelines. The OCaml guidelines do this, as do the older Python guidelines.

I'm not sure that including the whole .spec file would be helpful, but I think I can extract the relevant snippets instead. I'll work on that tomorrow.

If an edited example would be more useful for packagers, then that's another argument against linking to the package source.

application-only crates published on crates.io MAY drop rust- prefix

Just curious what's the reason for this? I mean, sometimes such libraries turn into the application+library and in that case it would require packager to rename package. OTOH having SRPM with rust- prefix should not cause any issues as a binary one is still without?

application-only crates published on crates.io MAY drop rust- prefix

Just curious what's the reason for this? I mean, sometimes such libraries turn into the application+library and in that case it would require packager to rename package. OTOH having SRPM with rust- prefix should not cause any issues as a binary one is still without?

This was in response to multiple occasions of people asking me "why do I have to package application x as rust-x if it only ships /usr/bin/x". But your point is a good one, crates can change from application-only to application+library at any point, which could introduce problems. I'll make some more changes to the PR.

rebased onto 67b6c288bb50e1765e768735279fde8b4bffe9ef

rebased onto 170e75b8710b5d0ef8fbd307d716b901bdafa154

I have updated the PR according to the feedback in previous comments.

LGTM

I think all raised issues have been addressed, can we move this PR forward? :wine_glass:

rebased onto a53382550e1f501e758ba58bef1758da9f00764f

I added a few more small improvements and cleanups, and removed the parts that were specific to Fedora < 34 (as Fedora 33 is EOL now).

rebased onto 90687f96bae1c3ed99520c547218eee8d09d843c

Pull-Request has been merged by tibbs
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.