On Mon, Jan 17, 2022 at 11:44 AM Darryl Bond <darrylb(a)fedoraproject.org> wrote:
I maintain a small application hosted on GitHub.
It allows control of USB connected electrical relays. Originally it was a simple command
Over the years, it has accumulated additional features such as a python interface, and an
There is a debian package that has not been maintained for many years. We are
endeavouring to fix that.
As a long term Fedora user, I would love to get it into Fedora. However I have never
attempted to create an rpm package. The more I read, the more confused I am.
Questions on Issues like:
Maybe I am able to answer some of your questions.
- How to clone the GitHub repository in the spec file
Short answer: You don't. RPM packages are (usually) built from
declarative "Source" files, not by manually executing steps to get
In this case, you would use the standard git archive / tarball
provided by GitHub for the release you want to package, with a
parametrized URL like this one:
This makes it possible to only change the version string in one place
and not having to update the Source URLs etc. too.
Then for Fedora packages, "spectool" is the tool used to download /
prepare those source files before building a source package.
"spectool -g usbrelay.spec" will parse your .spec file and download
the files from the URLs specified with Source0, Source1, etc.
"rpmbuild -bs usbrelay.spec" will then construct your source package,
assuming you place the files in the expected locations on file system.
"mock usbrelay-0.8-1.fc35.src.rpm" will then build your packages in
the standard clean sandbox that's used by all Fedora RPM builds.
- should there be one package or a separate python package.
That depends on the use case. Are the python bindings useful without
the command line interface?
Does the command line interface depend on the python bindings anyway?
If they are useful without each other, building a "python3-usbrelay"
package from the same "usbrelay" package is possible, you do not need
to create separate .spec files for that.
- what about the daemon/ systemd service...
Same applies here. If the application is useful without the
daemon+service, I'd split those off into a separate sub-package too.