Update RPM spec for Tito and Fedora compatibility

[BrianSipos]

This relocates the RPM spec file and corrects some typos in it to be compatible with Fedora Tito tooling and COPR integration.

This also adds a CI job to ensure that the spec gets exercised regularly and does not collect typos as releases occur.

[laurencelundblade]

Hi Brian, I'm working on this. I'm trying to understand the full package space -- .pc files and .spec files and the ongoing maintenance and such. It will also go across all my open source projects.

I appreciate your contributions a lot.

[BrianSipos]

For good news, the current state of this branch has been reviewed and approved by Fedora packagers https://bugzilla.redhat.com/show_bug.cgi?id=2465140

[BrianSipos]

Since you mention pkg-config .pc file, are you interested in having one installed as part of CMake or patched in via the RPM spec?

[laurencelundblade]

Yes, I'm interested in cmake making pkg-config .pc.

Getting closer to figuring out how to fit this all together...

[laurencelundblade]

I think I'm going to create CHANGELOG.md to carry the source of truth for changes version-version. I will copy only text for the most recent release into each GitHub version release.

Claude.ai thinks I should keep %changelog in qcbor.spec to a minimum like this:

`* Fri Jun 13 2026 Laurence Lundblade lgl@island-resort.com - 2.0.0-1

• Update to QCBOR 2.0.0; see CHANGELOG.md for details`

This seems OK to me. Claude.ai sez that %changelog is more about RPM package events than QCBOR releases on GitHub. The RPM guys will just copy what they need from qcbor.spec, which is probably not the blow-by-blow changes in CHANGELOG.md.

How does this sound to you?

[BrianSipos]

The package changelog is user visible, so should have just one main "why did this release happen" for each version. I think pointing to another file is discouraged.

About the pc file, would you prefer a separate PR to patch one into the rpm build? Or add to this PR?
A later draft can integrate it into cmake config (for a future release version).

[laurencelundblade]

For the pc file, a separate PR is probably better. Thx!

[laurencelundblade]

Not being much into RPM and packages I'm trying to figure this out by talking to claude.ai. Here's some of what it says:

%changelog entries are about the package's relationship to the distro — its build environment, its dependencies, its file layout, its compliance with that distro's rules, its coordination with other packages. None of them describe what QCBOR's code does differently. That's the dividing line:

• Upstream CHANGELOG.md answers "what changed in the software?" — new APIs, bug fixes, behavior changes.
• Spec %changelog answers "what changed about packaging the software for this distro?" — version bumps, rebuilds, patches, splits, metadata.

The %changelog published in qcbor.spec is really just a template that the packager uses as a starting point. It's not there for user's to look at and, according to claude.ai, even the %changelog in the package is not where users look for QCBOR SW changes.

I plan to scale this across all my open source C projects, so I need to be pretty sure about it, plus I really want to minimize maintenance/release overhead.

[laurencelundblade]

When I look at packages at https://koji.fedoraproject.org/koji/ their changelogs are as claude.ai describes. For example: https://koji.fedoraproject.org/koji/buildinfo?buildID=3014749

[BrianSipos]

I think it's up to you as source maintainer how to manage the log content. If you don't plan to use the Tito tool to do release tagging, I can remove it's config files from this PR. It is still helpful for the spec file to be in the root for automated tools.

[laurencelundblade]

I don't plan to do any packaging at this point. That seems more like a distro thing. They have the signing keys and their particular agendas. Maybe in the longer term -- for example libcurl seems to do some packaging.

I do want to distribute qcbor.spec and make sure it is in good shape to make it easy for the packagers. That can include using Tito in CI to check it, but I'm not clear on the full strategy yet.

Does that sound right?

[BrianSipos]

Yes that sounds fine. I've been out of the loop on official distro RPM packaging for a while, and tooling changes all the time. As of this comment this PR just updates the spec from Fedora review feedback and adds CI job to ensure the spec and its packages are all good (so that there are no accidental drifts that would break packaging).

[laurencelundblade]

I believe this line should be added in the %files devel section

%{_libdir}/pkgconfig/qcbor.pc

[laurencelundblade]

Also, add this comment near the top:

# Reference spec for QCBOR. The authoritative Fedora package is maintained 
# in Fedora dist-git; this copy may lag. QCBOR does not publish official
# binary packages — see README. Build from source via CMake.

Does this make sense?

Thanks again for the help here!