# Fedora Package Review: `libdnf5-plugins-rhsm`

**Bugzilla:** https://bugzilla.redhat.com/show_bug.cgi?id=2545849
**COPR Build:** https://copr.fedorainfracloud.org/coprs/jhnidek/rhsm-dnf5-plugins/build/11064385/
**Upstream:** https://github.com/candlepin/rhsm-dnf5-plugins
**Date:** 2026-10-13
**Assessment:** Multiple blockers must be fixed before approval

---

## 1. Package Overview

`libdnf5-plugins-rhsm` provides two libdnf5/DNF5 plugins for Red Hat Subscription
Management (RHSM):

| Plugin | Function |
|--------|----------|
| `rhsm` | Integrates DNF5 with RHSM certificate-based subscription entitlements |
| `productid` | Tracks installed product certificates (product identity) |

The project lives at https://github.com/candlepin/rhsm-dnf5-plugins (Candlepin /
Red Hat upstream). It is at an early but functional stage — version `0.1.2` is the
latest of two published releases; two additional planned plugins (`release`,
`reporefresh`) are listed as TODO in the README.

---

## 2. Artifacts Reviewed

| Artifact | Location | SHA-256 |
|----------|----------|---------|
| SRPM (upstream) | https://github.com/candlepin/rhsm-dnf5-plugins/releases/download/0.1.2/libdnf5-plugins-rhsm-0.1.2-1.fc44.src.rpm | `faa281f9f87b34a4795fc8cfdf002f2c310a504f823f7ba577508b4729969bac` |
| Source tarball (from SRPM) | `libdnf5-plugins-rhsm-0.1.2.tar.gz` | `0ce497d1f3f1d2b696bfc11b881c6b7b91506411be0bf6faa8fa17c1294481c1` |
| Spec file | https://download.copr.fedorainfracloud.org/results/jhnidek/rhsm-dnf5-plugins/srpm-builds/11064385/libdnf5-plugins-rhsm.spec | (within SRPM) |
| fedora-review report (rawhide-x86_64) | https://download.copr.fedorainfracloud.org/results/jhnidek/rhsm-dnf5-plugins/fedora-rawhide-x86_64/11064385-libdnf5-plugins-rhsm/fedora-review/review.txt | — |

---

## 3. Spec File (as reviewed)

```spec
Name:           libdnf5-plugins-rhsm
Version:        0.1.2
Epoch:          1
Release:        %autorelease
Summary:        Libdnf5 plugins for Red Hat Subscription Management
License:        GPL-3.0-only
URL:            https://github.com/candlepin/rhsm-dnf5-plugins
Source0:        %{name}-%{version}.tar.gz

%bcond_with     clang
%bcond_without  tests
%bcond_without  productid_libdnf5_plugin
%bcond_without  rhsm_libdnf5_plugin

%if %{with clang}
BuildRequires:  clang
%else
BuildRequires:  gcc-c++ >= 10.1
%endif
BuildRequires:  cmake >= 3.21
BuildRequires:  pkgconfig(libcrypto)
BuildRequires:  libdnf5-devel
BuildRequires:  jsoncpp-devel
%if %{with tests}
BuildRequires:  gtest-devel
%endif

%description
This package provides libdnf5 plugins to interact with repositories
and subscriptions from the Red Hat entitlement platform; contains
rhsm and product-id plugins.

%files

%{_libdir}/libdnf5/plugins/productid.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/productid.conf

%{_libdir}/libdnf5/plugins/rhsm.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/rhsm.conf

%prep
%autosetup -p1

%build
%cmake \
    -DWITH_TESTS=%{?with_tests:ON}%{!?with_tests:OFF} \
    -DWITH_PLUGIN_PRODUCTID=%{?with_productid_libdnf5_plugin:ON}%{!?with_productid_libdnf5_plugin:OFF} \
    -DWITH_PLUGIN_RHSM=%{?with_rhsm_libdnf5_plugin:ON}%{!?with_rhsm_libdnf5_plugin:OFF}
%cmake_build

%check
%if %{with tests}
    %ctest
%endif

%install
%cmake_install

%changelog
%autochangelog
```

---

## 4. rpmlint Output

rpmlint 2.8.0 run on the SRPM and spec file locally:

```
libdnf5-plugins-rhsm.spec: W: invalid-url Source0: libdnf5-plugins-rhsm-0.1.2.tar.gz
1 packages and 0 specfiles checked; 0 errors, 1 warnings, 4 filtered, 0 badness
```

rpmlint from COPR fedora-review (rawhide-x86_64), run against SRPM + binary RPM:

```
libdnf5-plugins-rhsm.spec: W: invalid-url Source0: libdnf5-plugins-rhsm-0.1.2.tar.gz
2 packages and 0 specfiles checked; 0 errors, 1 warnings, 8 filtered, 0 badness
```

**Result:** 0 errors, 1 warning. The single warning (`invalid-url Source0`) is directly caused
by Issue #2 below and is addressed there.

---

## 5. Build Results (COPR Build #11064385)

All 12 chroots built successfully:

| Chroot | Status | Build Time |
|--------|--------|-----------|
| fedora-44-x86_64 | ✅ succeeded | 15 min |
| fedora-44-aarch64 | ✅ succeeded | 14 min |
| fedora-44-ppc64le | ✅ succeeded | 11 min |
| fedora-44-s390x | ✅ succeeded | 28 min |
| fedora-45-x86_64 | ✅ succeeded | 13 min |
| fedora-45-aarch64 | ✅ succeeded | 13 min |
| fedora-45-ppc64le | ✅ succeeded | 9 min |
| fedora-45-s390x | ✅ succeeded | 24 min |
| fedora-rawhide-x86_64 | ✅ succeeded | 13 min |
| fedora-rawhide-aarch64 | ✅ succeeded | 13 min |
| fedora-rawhide-ppc64le | ✅ succeeded | 12 min |
| fedora-rawhide-s390x | ✅ succeeded | 26 min |

The package builds cleanly on all four Fedora primary architectures across Fedora 44,
45, and Rawhide.

---

## 6. Review Findings

### 🔴 BLOCKER #1 — `%license` directive is missing

**Guideline (MUST):** *"If (and only if) the source package includes the text of the
license(s) in its own file, then that file must be included in `%license`."*

**Evidence:** The source tarball (`libdnf5-plugins-rhsm-0.1.2.tar.gz`) contains a
`LICENSE` file at the top level of the project tree:

```
libdnf5-plugins-rhsm-0.1.2/LICENSE     ← full GPL-3.0 license text, confirmed present
```

This was confirmed by listing the tarball contents:

```
tar -tzf libdnf5-plugins-rhsm-0.1.2.tar.gz | grep -i license
libdnf5-plugins-rhsm-0.1.2/LICENSE
```

The `LICENSE` file contains the complete, unmodified GNU General Public License v3
text (GPLv3, dated 29 June 2007, Free Software Foundation).

**Problem:** The `%files` section contains **no `%license` line whatsoever**. The
license text will not be installed into the built binary package. This is a MUST
requirement failure (see https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text)

**Required fix:**

```spec
%files
%license LICENSE          ← ADD THIS LINE
%{_libdir}/libdnf5/plugins/productid.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/productid.conf
%{_libdir}/libdnf5/plugins/rhsm.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/rhsm.conf
```

---

### 🔴 BLOCKER #2 — `Source0:` contains no upstream URL

**Guideline (MUST):** *"The sources used to build the package must match the upstream
source, as provided in the spec URL. Reviewers should use sha256sum for this task."*
The [Source URL Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/)
additionally require that `Source0` contain a working URL to the upstream source so
that reviewers and the Fedora build system can verify the tarball's provenance.

**Evidence:**

```spec
Source0:        %{name}-%{version}.tar.gz      ← bare filename, NO URL
```

This is what triggers the rpmlint warning:

```
W: invalid-url Source0: libdnf5-plugins-rhsm-0.1.2.tar.gz
```

The upstream release at https://github.com/candlepin/rhsm-dnf5-plugins/releases/tag/0.1.2
provides a source tarball as a release asset. While the SRPM itself is hosted at
`https://github.com/candlepin/rhsm-dnf5-plugins/releases/download/0.1.2/libdnf5-plugins-rhsm-0.1.2-1.fc44.src.rpm`,
the source tarball **inside** the SRPM (`libdnf5-plugins-rhsm-0.1.2.tar.gz`) does not
appear to have a separate canonical URL distinct from a git archive.

**Required fix:** Use a proper upstream URL. If the tarball is generated from a git
archive, this must be documented in a spec comment. Candidate options:

```spec
# Option A — GitHub auto-generated tagged archive:
Source0: https://github.com/candlepin/rhsm-dnf5-plugins/archive/%{version}/%{name}-%{version}.tar.gz

# Option B — if upstream publishes a named release tarball asset directly:
Source0: https://github.com/candlepin/rhsm-dnf5-plugins/releases/download/%{version}/%{name}-%{version}.tar.gz
```

> ⚠️ **Option A requires additional spec changes and is not a drop-in fix.** GitHub's
> `/archive/<tag>/` endpoint ignores the filename component of the URL and always
> serves its auto-generated archive, named after the *repository* rather than the RPM
> package. Verified via HTTP inspection: the URL above resolves successfully but the
> `Content-Disposition` header of the response reveals the actual archive served is
> `rhsm-dnf5-plugins-0.1.2.tar.gz`, whose top-level directory is
> `rhsm-dnf5-plugins-0.1.2/` — not `libdnf5-plugins-rhsm-0.1.2/` as `%autosetup`
> would expect. Using Option A therefore requires two additional changes:
> 1. `%autosetup -p1` must gain a `-n rhsm-dnf5-plugins-%{version}` argument to match
>    the actual unpacked directory name.
> 2. The SHA-256 of the resulting tarball will differ from the current SRPM tarball
>    (`0ce497d1f3f1d2b696bfc11b881c6b7b91506411be0bf6faa8fa17c1294481c1`); the packager
>    must re-verify against the new artifact. Note that GitHub publishes no SHA-256 for
>    `/archive/` tarballs — only an ETag — so provenance verification depends on the
>    packager computing and documenting the digest independently.
>
> Option B (a named release asset URL) avoids the naming mismatch entirely but requires
> that upstream publish a separately named tarball as a GitHub release asset — which
> they do not currently do for version 0.1.2. If neither option is workable as-is, the
> packager should coordinate with upstream to publish a canonically named tarball asset,
> or document the tarball provenance in a spec comment as the minimum acceptable
> workaround per the Source URL guidelines.

---

### 🔴 BLOCKER #3 — `Epoch: 1` on a new package has no justification

**Guideline (MUST):** Packages must meet Packaging Guidelines. The Fedora Packaging
Guidelines ("Use of Epochs") state: *"[Epoch] should only be used in Fedora as a last
resort to resolve upgrade ordering of a package, and should be avoided wherever
possible."* Once set, an Epoch can never be removed from a package. The reviewer
additionally recommends that, if Epoch is retained, a spec comment document the reason.

**Evidence:**

```spec
Epoch:          1
```

`libdnf5-plugins-rhsm` is a **brand-new package** being submitted to Fedora for the
first time. A new package with no prior Fedora history should start at Epoch 0 (the
default when `Epoch:` is omitted). Setting `Epoch: 1` artificially inflates the
package's version epoch for all future releases.

The COPR build record confirms the effective EVR as `1:0.1.2-1`, meaning every future
version comparison for this package begins at epoch 1.

No justification comment exists in the spec file and none is provided in the BZ ticket.
Possible reasons for this epoch include:

- A prior COPR build used a higher release version (e.g., `0.1.2-2`) that needed to
  be superseded — but this should not affect the Fedora package.
- A different package previously occupied this name — no evidence of this was found.
- The epoch was added by mistake and should simply be removed.

**Required fix:** Either:
1. Remove `Epoch: 1` entirely (preferred for a new package), **or**
2. Add a spec comment explaining why Epoch 1 is necessary:
   ```spec
   # Epoch 1 required because <REASON>
   Epoch:          1
   ```

---

### 🟡 ISSUE #4 — Spec file section ordering harms legibility (SHOULD)

**Guideline (SHOULD):** The [Spec Legibility Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility)
state only that *"All spec files MUST be legible and maintained in such a way that the
community of packagers is able to understand and work with them."* No specific section
ordering is mandated — the conventional sequence appears only in example spec files
throughout the guidelines, not as a normative MUST or SHOULD requirement. Reordering
is therefore a strong courtesy recommendation, not a blocker.

**Evidence:** The spec file has `%files` placed **before** `%prep`, `%build`, `%check`,
and `%install`. Additionally, `%check` appears **before** `%install`, which is also
non-standard. The conventional order is:

```
Preamble (Name, Version, BuildRequires, etc.)
%description
%prep
%build
%install
%check
%files
%changelog
```

The current spec order is:

```
Preamble → %description → %files → %prep → %build → %check → %install → %changelog
```

While RPM processes spec sections correctly regardless of their textual order, this
layout makes the spec significantly harder to read and review — the `%files` section,
which lists what gets installed, appears before the sections that actually build and
install the software. The `%check`/`%install` inversion is also unusual.

**Recommended fix:** Reorder sections to follow the conventional order.

---

### 🟡 ISSUE #5 — Unversioned `.so` plugin files (NOTE — acceptable in context)

**Evidence** (from fedora-review):

```
Unversioned so-files
--------------------
libdnf5-plugins-rhsm: /usr/lib64/libdnf5/plugins/productid.so
libdnf5-plugins-rhsm: /usr/lib64/libdnf5/plugins/rhsm.so
```

The `%files` glob `%{_libdir}/libdnf5/plugins/productid.*` captures these files.

**Assessment:** These `.so` files are CMake MODULE libraries — they are plugin
binaries loaded at runtime via `dlopen()`, not shared libraries for linking. They are
installed in a **private** subdirectory (`/usr/lib64/libdnf5/plugins/`) that is **not**
in the standard dynamic linker search path (`/etc/ld.so.conf.d/`). Unversioned `.so`
files in private plugin directories are **acceptable** per Fedora guidelines.

No change is required here, but the reviewer documents this for completeness.

---

### 🟡 ISSUE #6 — `/usr/lib64/libdnf5/plugins` directory ownership (RESOLVED)

The `fedora-review` tool flagged this directory as having "unknown owners" in its
build environment. Manual investigation confirms:

```
$ rpm -ql libdnf5 | grep plugins
/usr/lib64/libdnf5/plugins

$ rpm -ql dnf5 | grep libdnf5
/usr/lib64/libdnf5/plugins
```

The directory `/usr/lib64/libdnf5/plugins` is owned by the `libdnf5` package (also
shared with `dnf5`). Since the spec auto-generates a `Requires: libdnf5.so.2` from the
binary dependency, the directory will always be present when this package is installed.

**Assessment:** ✅ No issue — the directory ownership concern raised by `fedora-review`
is a false alarm. The directory is owned by `libdnf5`, which is auto-required.

---

### 🟡 ISSUE #7 — No GPG signature verification in `%prep` (SHOULD)

**Guideline (SHOULD):** *"Sources are verified with gpgverify first in `%prep` if
upstream publishes signatures."*

**Evidence:** Both release tags `0.1.1` and `0.1.2` are **GPG-signed** by the committer
(`@jirihnidek`) with a verified GitHub signature. The `%prep` section does not use
`%{gpgverify}`.

**Assessment:** This is a SHOULD recommendation, not a blocker. The packager should
consider adding GPG verification if a detached signature or keyring can be published
alongside the release assets.

---

### 🟡 ISSUE #8 — Source tarball provenance undocumented (SHOULD)

The `fedora-review` tool notes: *"Package contains tarball without URL, check
comments."* There is no comment in the spec explaining whether the tarball is a raw
git archive, a generated release asset, or something else. This is directly related
to Blocker #2 (Source0 URL) and will be resolved when that is fixed.

---

## 7. Items That Pass

| # | Check | Guideline | Result |
|---|-------|-----------|--------|
| 1 | Package name `libdnf5-plugins-rhsm` uses allowed ASCII, follows naming conventions | MUST | ✅ PASS |
| 2 | Spec filename matches `%{name}` (`libdnf5-plugins-rhsm.spec`) | MUST | ✅ PASS |
| 3 | License field `GPL-3.0-only` is a valid SPDX expression | MUST | ✅ PASS |
| 4 | Upstream `LICENSE` file is full GPL-3.0 text — matches spec `License:` field | MUST | ✅ PASS |
| 5 | Package builds successfully on all four primary architectures (x86_64, aarch64, ppc64le, s390x) | MUST | ✅ PASS |
| 6 | Package builds on F44, F45, and Rawhide | MUST | ✅ PASS |
| 7 | rpmlint: 0 errors, 1 warning (Source0 URL — addressed in Issue #2) | MUST | ✅ PASS |
| 8 | No `.la` libtool archives | MUST | ✅ PASS |
| 9 | No static executables | MUST | ✅ PASS |
| 10 | No rpath issues (plugins use module-style linking, no rpath) | MUST | ✅ PASS |
| 11 | `%config(noreplace)` used for both `.conf` files | MUST | ✅ PASS |
| 12 | `BuildRequires: gcc-c++ >= 10.1` listed (C++20 requirement satisfied) | MUST | ✅ PASS |
| 13 | All runtime build dependencies listed: `cmake`, `pkgconfig(libcrypto)`, `libdnf5-devel`, `jsoncpp-devel`, `gtest-devel` (conditional) | MUST | ✅ PASS |
| 14 | CMake macros used correctly (`%cmake`, `%cmake_build`, `%cmake_install`, `%ctest`) | MUST | ✅ PASS |
| 15 | `%autorelease` and `%autochangelog` used | MUST | ✅ PASS |
| 16 | `%autosetup -p1` used in `%prep` | MUST | ✅ PASS |
| 17 | Package is not relocatable | MUST | ✅ PASS |
| 18 | No duplicate files in `%files` | MUST | ✅ PASS |
| 19 | No files in `/srv`, `/opt`, or `/usr/local` | MUST | ✅ PASS |
| 20 | No `%config` files under `/usr` | MUST | ✅ PASS |
| 21 | Package does not own files or directories owned by other packages | MUST | ✅ PASS |
| 22 | `/usr/lib64/libdnf5/plugins` directory owned by `libdnf5`; auto-required via `libdnf5.so.2` | MUST | ✅ PASS |
| 23 | No deprecated package dependencies | MUST | ✅ PASS |
| 24 | Not a GUI application — no `.desktop` file needed | MUST | ✅ PASS (N/A) |
| 25 | No static libraries | MUST | ✅ PASS |
| 26 | No bundled libraries | MUST | ✅ PASS |
| 27 | Spec Summary and `%description` written in American English | MUST | ✅ PASS |
| 28 | Package contains real compiled code (C++ plugins) | MUST | ✅ PASS |
| 29 | `%check` section present (`%ctest` when tests enabled) | SHOULD | ✅ PASS |
| 30 | Latest version packaged (0.1.2 is the most recent of 2 published releases) | SHOULD | ✅ PASS |
| 31 | No `%clean` section with `rm -rf %{buildroot}` | SHOULD | ✅ PASS |
| 32 | No `Packager`, `Vendor`, `PreReq`, or `Copyright` tags | SHOULD | ✅ PASS |
| 33 | No `%define` macros (uses `%global`/`%bcond`) | SHOULD | ✅ PASS |
| 34 | Dist tag present in Release | MUST | ✅ PASS |
| 35 | Install paths use CMake `FULL_LIBDIR`/`FULL_SYSCONFDIR` — no hardcoded paths | MUST | ✅ PASS |

---

## 8. Runtime Dependencies Analysis

Auto-generated `Requires` from the binary RPM (fedora-44-x86_64):

```
libdnf5-plugins-rhsm (rpmlib, GLIBC filtered):
    config(libdnf5-plugins-rhsm)
    libc.so.6()(64bit)
    libcrypto.so.3()(64bit)
    libcrypto.so.3(OPENSSL_3.0.0)(64bit)
    libdnf5.so.2()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.3.1)(64bit)
    libjsoncpp.so.26()(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.9)(64bit)
    rtld(GNU_HASH)
```

All runtime dependencies are auto-detected from the binary and are correct:
- `libdnf5.so.2` — the DNF5 library (loads and calls the plugins)
- `libcrypto.so.3` / OpenSSL — used for certificate handling in both plugins
- `libjsoncpp.so.26` — used by the `productid` plugin for product JSON parsing
- `libgcc_s`, `libstdc++` — C++ runtime, expected for a C++20 binary

No extraneous or missing runtime dependencies are apparent. Note that
`subscription-manager` (the RHSM client) is NOT a hard dependency — the plugin
reads RHSM configuration and certificate files directly, so the plugin can be
installed independently.

---

## 9. Licensing Summary

| Item | Detail | Status |
|------|--------|--------|
| Spec `License:` field | `GPL-3.0-only` (valid SPDX) | ✅ |
| Upstream `LICENSE` file | Full GPLv3 text (29 June 2007, FSF) | ✅ |
| GitHub detected license | GPL-3.0 | ✅ |
| License in tarball | `libdnf5-plugins-rhsm-0.1.2/LICENSE` — GPLv3 full text | ✅ |
| `%license` directive in spec | **MISSING** — blocker #1 | ❌ |
| `licensecheck` result (from COPR) | "GNU General Public License, Version 3" + 42–43 files "Unknown or generated" | ⚠️ |

The 42–43 "Unknown or generated" files identified by `licensecheck` are test data
(`.pem` certificate files, `.gz` product ID files, CMake-generated files, and CI
configuration). These are not separately licensed works and do not require their own
license entries. The core source files (`.cpp`, `.hpp`) are GPL-3.0 consistent with
the `LICENSE` file.

---

## 10. Source Verification

The SRPM was downloaded from the upstream GitHub release page and its SHA-256 verified:

```
$ sha256sum libdnf5-plugins-rhsm-0.1.2-1.fc44.src.rpm
faa281f9f87b34a4795fc8cfdf002f2c310a504f823f7ba577508b4729969bac
```

The source tarball extracted from the SRPM:

```
$ sha256sum libdnf5-plugins-rhsm-0.1.2.tar.gz
0ce497d1f3f1d2b696bfc11b881c6b7b91506411be0bf6faa8fa17c1294481c1
```

The SRPM was published at the GitHub `0.1.2` release tag, which is also GPG-signed
by the committer (`@jirihnidek`). The tarball inside the SRPM is consistent with
the project at tag `0.1.2`. Source URL verification cannot be fully automated because
`Source0` has no URL (Blocker #2), but the SRPM itself originates from the correct
upstream release.

---

## 11. Summary of Required Changes

### Must Fix Before Approval (Blockers)

| # | Issue | Fix Required |
|---|-------|-------------|
| B1 | **Missing `%license` directive** | Add `%license LICENSE` to `%files` section |
| B2 | **`Source0:` has no upstream URL** | Set `Source0:` to a proper `https://github.com/...` URL (see Blocker #2 for caveats on Option A) |
| B3 | **`Epoch: 1` unjustified** | Remove `Epoch: 1` or add a spec comment with justification |

### Should Fix (Recommendations)

| # | Issue | Recommendation |
|---|-------|---------------|
| R1 | No GPG verification in `%prep` | Add `%{gpgverify}` if upstream publishes detached signatures |
| R2 | Tarball provenance undocumented | Resolved by fixing B2 (add Source0 URL) |
| R3 | Non-standard spec section ordering | Reorder: `%prep` → `%build` → `%install` → `%check` → `%files` → `%changelog` (convention, aids legibility) |

### No Action Required

| # | Issue | Reason |
|---|-------|--------|
| N1 | Unversioned `.so` files | These are private MODULE plugins, not in ld path — acceptable |
| N2 | `/usr/lib64/libdnf5/plugins` directory ownership | Owned by `libdnf5`, auto-required — no issue |
| N3 | 42–43 files flagged "unknown" by `licensecheck` | Test data / generated files — not separately licensed |

---

## 12. Corrected Spec File (Illustrative)

The following shows the spec file with all blockers fixed. **`Source0` is shown as a
placeholder** — see the note below and Blocker #2 for the reasons why the URL cannot
be filled in mechanically.

```spec
Name:           libdnf5-plugins-rhsm
Version:        0.1.2
# Epoch removed — new package, no prior Fedora history requiring epoch override
Release:        %autorelease
Summary:        Libdnf5 plugins for Red Hat Subscription Management
License:        GPL-3.0-only
URL:            https://github.com/candlepin/rhsm-dnf5-plugins
# TODO (packager): Supply a verified upstream URL for Source0.
# Option A (GitHub auto-archive) requires additional changes — see Blocker #2 note.
# Option B requires upstream to publish a named tarball release asset.
Source0:        %{name}-%{version}.tar.gz

%bcond_with     clang
%bcond_without  tests
%bcond_without  productid_libdnf5_plugin
%bcond_without  rhsm_libdnf5_plugin

%if %{with clang}
BuildRequires:  clang
%else
BuildRequires:  gcc-c++ >= 10.1
%endif
BuildRequires:  cmake >= 3.21
BuildRequires:  pkgconfig(libcrypto)
BuildRequires:  libdnf5-devel
BuildRequires:  jsoncpp-devel
%if %{with tests}
BuildRequires:  gtest-devel
%endif

%description
This package provides libdnf5 plugins to interact with repositories
and subscriptions from the Red Hat entitlement platform; contains
rhsm and product-id plugins.

%prep
%autosetup -p1

%build
%cmake \
    -DWITH_TESTS=%{?with_tests:ON}%{!?with_tests:OFF} \
    -DWITH_PLUGIN_PRODUCTID=%{?with_productid_libdnf5_plugin:ON}%{!?with_productid_libdnf5_plugin:OFF} \
    -DWITH_PLUGIN_RHSM=%{?with_rhsm_libdnf5_plugin:ON}%{!?with_rhsm_libdnf5_plugin:OFF}
%cmake_build

%install
%cmake_install

%check
%if %{with tests}
    %ctest
%endif

%files
%license LICENSE
%{_libdir}/libdnf5/plugins/productid.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/productid.conf
%{_libdir}/libdnf5/plugins/rhsm.*
%config(noreplace) %{_sysconfdir}/dnf/libdnf5-plugins/rhsm.conf

%changelog
%autochangelog
```

> **Note on `Source0`:** No single URL can be filled in here without packager action.
> GitHub's `/archive/<tag>/` URL (Option A in Blocker #2) resolves successfully but
> serves a tarball whose top-level directory is `rhsm-dnf5-plugins-0.1.2/` — not
> `libdnf5-plugins-rhsm-0.1.2/` — causing `%autosetup` to fail without a `-n` override.
> It would also produce a different SHA-256 than the current tarball in the SRPM
> (`0ce497d1f3f1d2b696bfc11b881c6b7b91506411be0bf6faa8fa17c1294481c1`), and GitHub
> publishes no canonical digest for auto-generated archives. The packager must resolve
> the Source0 URL in coordination with upstream before this spec can be submitted.

---

## 13. Final Assessment

**Decision: ⚠️ NEEDS WORK**

The package is technically sound — it builds cleanly across all primary Fedora
architectures and all supported releases, the license is correct and Fedora-approved
(GPL-3.0-only), the build system usage is idiomatic, runtime dependencies are
auto-detected correctly, and rpmlint is clean of errors.

However, three MUST-level issues prevent approval:

1. The license file present in the tarball is not being installed via `%license` — a
   mandatory requirement when license text is shipped upstream.
2. `Source0` contains no URL, preventing automated source verification. Resolving this
   requires coordination with upstream to determine the correct URL and its implications
   for the tarball's name and SHA-256 (see Blocker #2 for details).
3. `Epoch: 1` is set without explanation on a new Fedora package.

Additionally, the non-standard spec section ordering (Issue #4) is a legibility
concern that should be addressed, though it is not a guideline-mandated blocker.

All required changes are confined to the spec file. Once fixed and a rebuilt SRPM
is provided, the package should be in good shape for approval.

---

*Review conducted using: rpmlint 2.8.0, fedora-review 0.12.0 (COPR-provided),
manual inspection of spec, tarball, upstream GitHub repository, and COPR build logs.*

Hi,
I created a new build: https://copr.fedorainfracloud.org/coprs/jhnidek/rhsm-dnf5-plugins/build/11208494/ ... only two tests failed due to infrastructure issues

I also created another build last week with the same source code, but using srpm: https://copr.fedorainfracloud.org/coprs/jhnidek/rhsm-dnf5-plugins/build/11196645/ and you can see that all tests passed.

I triggered an new build with the same spec file: https://copr.fedorainfracloud.org/coprs/jhnidek/rhsm-dnf5-plugins/build/11209718/ and everything is green now.

The Pagure repository was created at https://src.fedoraproject.org/rpms/libdnf5-plugins-rhsm
Monitoring:
Wasn't able to create project in Anitya. You can create it manually on: `https://release-monitoring.org`

FEDORA-2026-0c58724879 (libdnf5-plugins-rhsm-0.1.3-1.fc46) has been submitted as an update to Fedora 46.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-0c58724879

FEDORA-2026-0c58724879 (libdnf5-plugins-rhsm-0.1.3-1.fc46) has been pushed to the Fedora 46 stable repository.
If problem still persists, please make note of it in this bug report.