Add .spec file for RPM build on COPR

[christophehenry]

I do not guarantee this .spec file is compilant with Fedora's rules but it should run as is on COPR. Can you open an account and test it?

Fixes #213

[Falcosc]

Who does maintain this version number? There is a risk that we forget to change it during the release.

[christophehenry]

That is a good question. As COPR integrates with Github hooks, there should be a variable for it. I will dig into it.
Edit: It appears not. This number will need to be changed with each new release. Sorry I didn't think of warning you about that.

[christophehenry]

There seem to be a tool named Tito that manages the .spec metadata but I don't know how it works.

[joka90]

That's it, the packages builds correctly on COPR.

So, basically, this is how you should maintain the .spec file:

* change the `Version` variable to the next version release before tagging a new git version,

* also add a new entry at the top of the `%changelog` section summarizing the changes in the `.spec` file, if any; if none, just add "_Update to version x.y.z_".

A new entry in the %changelog section should look like this:

* Day-of-Week Month Day Year Name Surname <email> - Version-Release
- list of changes

If the build process doesn't change, this spec file should be stable over time.

Don't know if it is possible to use the 'tito' tool to change the version to "git describe" as of the github actions in my PR. I.E will change the version of each commit.

You should be able to build the package inside a docker container in the same github action flow.

As for the change log. It is more of importance to track per distro changes, not upstream changes. I.E if the distro specific stuff is upstream we don't need to keep the change log as strict as a normal Debian/rpm package.

Regarding the packaging in this PR. Maybe we could follow the same "app", lib and lib-dev ? Think it should be quite easy in .spec. Probably should rebase this change on top of mine to get the "install target" from cmake correct.

[Falcosc]

@christophehenry could you document how to use it in the README.md? I don't know why you choose the path "scripts/" and I am worried that we could break your contribution if we change the folder name.

I can not open an account to test it, if it is untestet you can mention it in your README.md change that it is only testet on COPR

[christophehenry]

The location of the .spec file is of no importance. It's just simpler to put it in the same repo that the code but the spec file actually doesn't need the code to correcty work since it will fetch the tarball from this URL.

It is a pretty standard .spec file here. All you need to do to build manually on Fedora (packages name may differ on other RPM distrib) is:

1. install the RPM dev tools with dnf install -y rpmdevtools rpmlint,
2. create ~/rpmbuild/SPECS and place RyzenAdj.spec here,
3. fetch the source tarball with spectool -g -R SPECS/RyzenAdj.spec; this command should create ~/rpmbuild/SOURCES/v%{version}.tar.gz with %{version} the version of the code currently built,
4. install the build requirement with dnf builddep SPECS/RyzenAdj.spec
5. and, finally, build the package with rpmbuild -ba SPECS/RyzenAdj.spec

The build directory may be placed elsewhere than ~/rpmbuild but you need to explicitely tell spectool and rpmbuild commands by always passing --define "_topdir $(pwd)" to the command. This is a bit cumbersome.

[christophehenry]

I am currently testing the build on COPR and it turns out I forgot a few build dependancies that I didn't spot because they were already installed here. Let me fix that.

[christophehenry]

That's it, the packages builds correctly on COPR.

So, basically, this is how you should maintain the .spec file:

• change the Version variable to the next version release before tagging a new git version,
• also add a new entry at the top of the %changelog section summarizing the changes in the .spec file, if any; if none, just add "Update to version x.y.z".

A new entry in the %changelog section should look like this:

* Day-of-Week Month Day Year Name Surname <email> - Version-Release
- list of changes

If the build process doesn't change, this spec file should be stable over time.

[Falcosc]

Don't forget to extend the README.md file with a note about COPR installation.

And for release management, you could discuss solutions with @joka90 because he has introduced the same issue #212 (comment) and did introduce another changelog file as well.

[christophehenry]

I'm sorry, I don't think I'll have the time to finish this. I hope someone can take over this work in the future.