#1026 update Rust guidelines and example spec files
Merged by decathorpe. Opened by decathorpe.
Unknown source master

Download 1026.patch
  • mention rust2rpm more prominently since it creates 99% Guidelines-compliant
    spec files
  • BuildRequires are now automatically generated and no longer have to be
    specified manually
  • include how to generate the effective License tag for subpackages containing
    statically linked Rust binaries
  • Modularity is no longer used for building on any branch, add a short note
    about the build process for Rust packages
  • crate packages will start being available with fedora 34 in addition to
    rawhide (see the F34 System-Wide Change page for details:
    https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches )
  • refreshed .spec file examples with current specs from rawhide

fedora -> Fedora

linux -> Linux

rebased onto dd7d37b9c6f243f427234ed54cdaf69d86ebd675

@ngompa thanks, I fixed all non-code-occurrences of "Fedora" and "Linux"

rawhide -> Rawhide

@decathorpe one last thing, and then this is good to go!

done!

I hope the new text is at least somewhat coherent and comprehensible :)

rebased onto f8762a708208256d6a04f624d2ba7ca378d56a1f

:thumbsup:

rebased onto 7407cd63420ff070e80b0d4160222cd5778fe6a6

I added a short note to mention the general Updates policy exception that was granted to source-only Rust packages (with a link to the FESCo ticket):

--- a/guidelines/modules/ROOT/pages/Rust.adoc
+++ b/guidelines/modules/ROOT/pages/Rust.adoc
@@ -249,6 +249,12 @@ CAUTION: The build process for Rust packages has evolved over time,
   packages for both library crates *and* applications will be available and built normally,
   without having to rely on a special procedure for release branches.
+NOTE: Source-only Rust packages were granted a general exception to the
+      https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates policy],
+      so they can be freely updated in release branches in addition to rawhide
+      (announced in the corresponding FESCo ticket:
+      https://pagure.io/fesco/issue/2474[F34 System-Wide Change: Rust Crate Packages For Release Branches]).
+
 == Examples
 === Library crate

:thumbsup:

rebased onto d4b7555cef65eebfbe35d64c2a23e3de98e8d99c

rebased onto ac06d002b8b0eab94b71163de84c4f7aa70ca7c3

Let's not mention slow, painful and not-fully-correct method. Let's use our helper instead (if we need to get it packaged properly - feel free to send PR).

https://pagure.io/fedora-rust/rust2rpm/blob/master/f/tools/fedora-helper.py

(see help from it about usage)

I think we need to be more descriptive on whether this actually is requirement or not. More specifically, about Obsoletes - whether we need anything like that.

rebased onto 0a8ee3def8a76c95294dffe7434c28811df48326

rebased onto 4ccb9200c39cd3a41604017e989f5e1c16e36933

Let's not mention slow, painful and not-fully-correct method. Let's use our helper instead (if we need to get it packaged properly - feel free to send PR).

https://pagure.io/fedora-rust/rust2rpm/blob/master/f/tools/fedora-helper.py

(see help from it about usage)

I updated the text. I didn't know about this script, it looks useful. Why isn't it packaged with rust2rpm yet? :)

I think we need to be more descriptive on whether this actually is requirement or not. More specifically, about Obsoletes - whether we need anything like that.

I'm not sure what you mean here. Why would we need Obsoletes, and for which packages?

I updated the text. I didn't know about this script, it looks useful. Why isn't it packaged with rust2rpm yet? :)

Well, nobody asked for it and I did not have time to do it myself yet :) So PR is very welcomed.

I'm not sure what you mean here. Why would we need Obsoletes, and for which packages?

E.g. if we update rust-foo and rust-foo+something-devel disappears, do we care about Obsoletes?

E.g. if we update rust-foo and rust-foo+something-devel disappears, do we care about Obsoletes?

I don't think we do, or do we? There's no reason for anybody to install the rust-foo-devel packages (let alone rust-foo+feature-devel packages) in any other environment than a temporary mock buildroot, so I don't see this as a problem.

Then +1 from me

Thanks! Any objections to merging this PR?

Last 3 comments and I think we are good:

  1. Update last-reviewed field :)
  2. I think it would worth mentioning that packagers SHOULD NOT enable tests for "compat" packages because usually that involves keeping more packages on old versions or unnecessary maintenance burden.
  3. Given blatant commits like https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master I think we should have rule "MUST NOT use vendored crates if all dependencies are available in the repository". To some extent it is repeating general bundling guidelines but I think in more places we mention it - would be better. And I'll have official reason to revert that commit :)

@ignatenkobrain does this look good?

--- a/guidelines/modules/ROOT/pages/Rust.adoc
+++ b/guidelines/modules/ROOT/pages/Rust.adoc
@@ -1,5 +1,5 @@
 = Rust Packaging Guidelines
-:last-reviewed: 2020-10-22
+:last-reviewed: 2021-01-24
 CAUTION: The workflow for Rust packaging on Fedora will be different starting with Fedora 34.
          Older releases (up until Fedora 33) do not ship source-only packages for Rust crates,
@@ -53,6 +53,12 @@ but the packager SHOULD query upstream to include those missing files in their p
 All Rust packages MUST have `+BuildRequires: rust-packaging+`.
+NOTE: As stated in the general xref:index.adoc#bundling[Packaging Guidelines],
+      packages MUST be built against system libraries, if that is possible.
+      For Rust, this means that packages MUST NOT use dependencies from a "vendor tarball"
+      (e.g. crated by running `+cargo vendor+`),
+      but package all library dependencies separately.
+
 === Automatic Dependency Generation
 `rust-packaging` automatically creates Requires and Provides
@@ -152,6 +158,11 @@ The package for the _older_ version MUST be adapted to remove its binary subpack
 so it only contains `-devel` subpackage(s) but no `+%{crate}+` subpackage,
 which would conflict with the corresponding package from the newer version of the crate.
+NOTE: When introducing a compatibility package, the packager SHOULD check
+      if keeping the test suite enabled causes additional unwanted dependencies,
+      for example, on other compatibility packages, or on old versions of other packages.
+      If that is the case, the test suite SHOULD be disabled to lower the overall maintenance burden.
+
 == ExclusiveArch
 All rust packages MUST have `+ExclusiveArch: %{rust_arches}+`.

(diff pasted for convenience)

rebased onto e0eb9271b4e9e0ba1c9af7ad7d8a54a6893176cc

+1

"if that is technically possible."

Could you please include examples for a possible and impossible case? Packagers should not use "it's too much work" as an excuse for using vendored crates.

It's also worth pointing to https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling so packagers include "Provides: bundled(rust-) = " when they use bundled crates.

Could you please include examples for a possible and impossible case? Packagers should not use "it's too much work" as an excuse for using vendored crates.

I can, but those reasons are the same for all packages, and not special for Rust packages. The only thing I can think of that might be worth mentioning is that if crates use "internal" dependencies that are not published on crates.io or if they apply patches on top of other crates, bundling is the only thing you can do (other than work with upstream to not do such awful things). :smiling_imp:

It's also worth pointing to https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling so packagers include "Provides: bundled(rust-) = " when they use bundled crates.

Actually, xref:index.adoc#bundling[Packaging Guidelines] expands to exactly this link when processed.

Provides: bundled(rust-) =

Provides: bundled(crate(<crate_name>)) = <version>

The only thing I can think of that might be worth mentioning is that if crates use "internal" dependencies that are not published on crates.io or if they apply patches on top of other crates, bundling is the only thing you can do (other than work with upstream to not do such awful things).

Sounds good to me! IMHO explicit is better than implicit and avoids ambiguities.

Provides: bundled(crate(<crate_name>)) = <version>

Nice! :thumbsup:

However, two common reasons that can make building a package
against system libraries (crates) basically impossible are
if a crate applies downstream patches on top of its dependencies,
or if it depends on "internal" crates that are not published on crates.io.
In these circumstances, packagers MAY use bundled dependencies,
but - if possible - SHOULD work with upstream to, for example,
make their downstream patches unnecessary, or publish internal crates.
If bundled dependencies are used to build a binary package,
the subpackage package that will contain the compiled binary
MUST have `+Provides: bundled(crate(foo)) = version+` for each bundled crate
and keep this list of crates and their versions up-to-date.

Does this sound good?

@decathorpe LGTM.

Metadata Update from @ignatenkobrain:
- Pull-request tagged with: meeting, rust

Fixed a few typos and applied the changes from the last comment. Diff:

diff --git a/guidelines/modules/ROOT/pages/Rust.adoc b/guidelines/modules/ROOT/pages/Rust.adoc
index 3b8daa4..8412bda 100644
--- a/guidelines/modules/ROOT/pages/Rust.adoc
+++ b/guidelines/modules/ROOT/pages/Rust.adoc
@@ -53,12 +53,28 @@ but the packager SHOULD query upstream to include those missing files in their p
 All Rust packages MUST have `+BuildRequires: rust-packaging+`.
+=== Bundled Dependencies
+
 NOTE: As stated in the general xref:index.adoc#bundling[Packaging Guidelines],
       packages MUST be built against system libraries, if that is possible.
       For Rust, this means that packages MUST NOT use dependencies from a "vendor tarball"
       (e.g. crated by running `+cargo vendor+`),
       but package all library dependencies separately.
+However, two common reasons that can make building a package
+against system libraries (crates) basically impossible are
+if a crate applies downstream patches on top of its dependencies,
+or if it depends on "internal" crates that are not published on crates.io.
+In these circumstances, packagers MAY use bundled dependencies,
+but - if possible - SHOULD work with upstream to, for example,
+make their downstream patches unnecessary, or publish internal crates.
+
+If bundled dependencies are used to build a binary package,
+the subpackage that will contain the compiled binary
+MUST have `+Provides: bundled(crate(foo)) = version+` for each bundled crate
+and the packager MUST keep this list of crates and their versions up-to-date
+every time the package or its bundled dependencies are updated.
+
 === Automatic Dependency Generation
 `rust-packaging` automatically creates Requires and Provides

rebased onto 5cf75ed1b1d422861447979c07ea03e1f102fecf

rebased onto 253e956cc3b439f5d0640c730bd197b73be2105a

Fedora 34 has branched, and the PR fixes documentation regarding Changes in Fedora 34.
I see five +1 votes (including mine, obviously), is it OK to merge this PR now?

Yes, go for it! :thumbsup:

Pull-Request has been merged by decathorpe

Metadata