rpmbuild requires that Source0’s basename be the same as the actual source archive present in the SOURCES directory.
It is very easy to rename the downloaded source archive, but this makes review of the package SPEC manual. A co-maintainer or a new maintainer would need to discover that I renamed the source archive just to satisfy rpmbuild's insistence on parity.
Here is an example changelog entry:
Changed the tar command in .spec file to address discrepancy between GitHub archive URI and downloaded source archive.
I should have indicated that I renamed the downloaded archive in the changelog, but otherwise it was a simple annoyance.
Personally, as a sysadmin, my issue now is fighting between making a RPM or an Ansible Role for landing custom tools or changes to a system. With a lot of orgs and teams using Ansible for their automation it makes it hard to argue to having a RPM build system rather then an Ansible control node or Tower.
I found it confusing that there are not just packages and .spec files to build them, but also “package sources” and “source packages”, where “source package” is not just upstream sources, but it is RPM binary file (SRPM) that is built from .spec files that are stored in “package sources” repositories.
I would really a prefer simplified approach - where “packages” are built from “sourcepacks”, where “sourcepack” is a file tree with upstream source and metadata (.spec). So you have “package” built from “sourcepack” and there is nothing else. “Sourcepack” is a hashed directory tree. It can be an identical unpacked dir, git repo or archive as long as tree hash matches. I don’t get why binary SRPM format for “source package” is needed when they just could just be a simple .zip archive or whatever.
I also don’t like that I can not mark packages as not manually installed. As a dependency of some other package. Like if I manually install some codecs for VLC, I want to mark them as dependent on VLC, so what when VLC is gone, these codecs are gone too.
I tried to make my own RPM like 3 times, and still can’t remember how to do it after python packaging workshop at the Nest conference. It is no YAML, no single tool that build everything from that single YAML. A lot of rituals with hashes and file placements (or was it in Debian?).
@abitrolly I follow this doc to get started, RPM Packaging Guide This helps me setup a VM for packaging and signing RPM’s. I good example I use is the SOS GitHub for setting up a RPM spec file for python application, the setup.py for the application, and add man pages if you application needs it. If you need any further help I can try and help.
I’d recommend you try again. I’ve been helping folks with no packaging experience package up simple python modules, and they’ve been able to follow along well enough to now be sponsored package maintainers. The new Python guidelines really make packaging quite easy.
There is only one spec file for RPM packages, that includes all the information needed to build a package. I don’t know what the Debian system is.
Some of this is just historical. The source RPMs really are just cpio archives (an old Unix format which had some generally-now-irrelevant advantages over tar) with a header. That’s probably not how we’d design it now, but eh.
However, in most modern workflows, you don’t really need to worry about the source package. That’s just a convenient bundle that we can put together with others to make sure we’re meeting our license obligations and etc. In most practical work, what you deal with is a dist-git tree — that is, like https://src.fedoraproject.org/ or CentOS rpms on gitlab.
But, you may be interested in going one step further to source-git — see Source Git :: Fedora Docs. This is, effectively, a work-in-progress implementation of some of the “more interesting improvements” that former Fedora Release Engineering team lead Jesse Keating laid out when announcing the creation of dist-git (from dist-cvs!) way back in 2010.