Bug 2107365

Summary:	please drop Rust library subpackages
Product:	[Fedora] Fedora	Reporter:	Fabio Valentini <decathorpe>
Component:	nmstate	Assignee:	Gris Ge <fge>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	ferferna, fge, liangwen12year, opensource
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-08-29 02:10:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Fabio Valentini 2022-07-14 20:01:06 UTC

Only crates that are published on crates.io may be packaged as Rust libraries, this is a MUST requirement from the Rust Packaging Guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_package_sources

It appears that the Rust bindings were added with the update to version 2.1.0, because I do not see them discussed in this package's review request.

It looks like the Rust library interface of nmstate is unused in Fedora. If this is the case, the simple way to fix this problem might be to just skip calling %cargo_install, and to drop the rust-nmstate-devel and rust-nmstate+default-devel sub-packages again.

There's also other problems with the Rust part of the package, for example, not defining the %{crate} macro might cause unintended consequences when calling other %cargo_* macros, and the %cargo_generate_buildrequires call is missing, which is why you appear to be manually keeping the list of BuildRequires up-to-date (though you don't use the correct / up-to-date syntax there).

Comment 1 Gris Ge 2022-07-27 05:46:05 UTC

The `rust-nmstate` will be required by coreos-installer https://github.com/coreos/coreos-installer/pull/864

Anyway, I will submit new package review and remove this subpakage.

Comment 2 Fabio Valentini 2022-07-27 09:16:30 UTC

I see now that nmstate is actually published on crates.io:
https://crates.io/crates/nmstate/

Would it be possible to use the sources from there instead of those from github, and package nmstate as "rust-nmstate"?
Then you could definitely keep all the -devel subpackages.

The main reasons for not allowing rust-foo-devel packages for Rust code that's not from crates.io are
1) namespace collisions (which is not a problem here, since nmstate is also published there), and
2) relying on standardized source layout and Cargo.toml files in our Rust tooling in Fedora (which *might* be a problem for *you* in the future, if nmstate upstream project starts to use any Cargo.toml syntax or features that aren't supported by our tooling OOTB).

Comment 3 Gris Ge 2022-08-02 06:47:28 UTC

The nmstate has many parts:
 1. CLI tool
 2. rust crate/library
 3. C library
 4. Python binding

Only the source of rust crate/library is uploaded to crates.io.
Let me find out whether we have alternative way to fix this besides request a brand-new package dedicate for `rust-nmstate`.

Comment 4 Fabio Valentini 2022-08-02 07:30:07 UTC

I can propose a change to the Rust Packaging Guidelines for this case, someting like

"If you cannot package Rust sources from crates published on crates.io, but still need to ship Rust crate source code for use in dependent packages, then packaging Rust crates from other sources is only allowed if the crate's source code is *also* published on crates.io *under the same name*, to avoid namespace collisions."

I think that would solve the problem for nmstate and nispor?

Comment 5 Ben Cotton 2022-08-09 13:22:10 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 6 Gris Ge 2022-08-23 06:32:07 UTC

(In reply to Fabio Valentini from comment #4)
> I can propose a change to the Rust Packaging Guidelines for this case,
> someting like
> 
> "If you cannot package Rust sources from crates published on crates.io, but
> still need to ship Rust crate source code for use in dependent packages,
> then packaging Rust crates from other sources is only allowed if the crate's
> source code is *also* published on crates.io *under the same name*, to avoid
> namespace collisions."
> 
> I think that would solve the problem for nmstate and nispor?

Yes. That would ideal. Maintaining two rpm packages (one for bin files, one for rust-crate) for single project is also OK to me.
Then who (robot?) will enforce this?

Comment 7 Fabio Valentini 2022-08-23 11:51:39 UTC

I've submitted a Pull Request to update the Rust Packaging Guidelines for this:
https://pagure.io/packaging-committee/pull-request/1204

I think the exception for "complex" projects that ship Rust crate code that is *also* published under the same name on crates.io should cover these two packages. What do you think?

Comment 8 Gris Ge 2022-08-29 02:10:37 UTC

I noticed the updated `Rust Packaging Guidelines` allows nmstate shipping both bindings/cli/crates in single srpm now:

Complex projects with multiple components (i.e. bindings for other languages), which cannot be packaged from sources that are published on crates.io alone, MAY include subpackages for their Rust library interface (rust-$crate-devel, rust-$crate+feature-devel, etc.) ONLY if this crate is also published on crates.io under the same name.


Thanks for the help!

Closing as not a bug.