Added rpm spec compatible with openSUSE 15.4 #5
Conversation
|
@twojstaryzdomu Thanks for PR and sorry for delay. I'm going to merge the PR and test CI builds and debian packages. However I have two small concerns: Do we ever need to install this tools? I think they are internal tool + examples + tests and are needed only during development on developer machine. Maybe we should remove libopenfec-tools at all? And another small question regarding |
|
If you think some of these concerns should be addressed, it would be great if you could do it in subsequent PRs. |
|
Follow-up commit: d89dba2 Now CI runs simple build (cmake + make) on any push and pull request, and runs packaging steps only on push to versioned tag. I created a test tag v9.9.9. The build succeeded: https://github.com/roc-streaming/openfec/actions/runs/3554057286 It generated github release openfec_9.9.9: https://github.com/roc-streaming/openfec/releases/tag/untagged-d4f9158b4e447065ff7f I was not able to install the generated debian package: |
|
https://unix.stackexchange.com/questions/669004/zst-compression-not-supported-by-apt-dpkg I'm running debian stable. Maybe we could make packages compatible with it? |
|
I was able to install packages inside docker container with ubuntu. I see two minor problems with
|
|
Also I think here: we should also add |
|
One more follow-up commit: 695498e Package version in cmake is now automatically extracted from latest git tag. |
|
I've summarized issues with debian packages in #7. |
|
I've removed v9.9.9 and tagged v1.4.2.5 with recent fixes. |
In keeping tools as a package I followed a convention for most debian builds whereby any binaries for library builds are packaged either as -tools or -utils. I recognise they're not strictly necessary but there is little cost to keeping them included.
The version is sadly hardcoded in the contents of the file. Keeping the version in the filename was my way of indicating the contents of the file are specific to that version. Whenever the version is bumped up, the record for the Version inside the file requires an update. So with your raising the minor version number, the spec file needs to be renamed and updated accordingly. What is needed for the update to be automatic is a GH-specific CI running before the release runs, so that the updated spec file is included in the GH sources accompanying the release. The CI needs to look up the variable for the latest version and update it if needed inside the file. Is this supplementary package going to be updated often though to be worth the effort of putting a CI in place? Any users looking for a |
Yeah, I see. But I think they are not just unnecessary, but may confuse the users? Because I don't see any use case for them outside of the source tree (when you're developing openfec itself). And also if you install them, they will pollute your PATH with strange names like "simple_server". I believe they were not ever intended for system-wide installation.
Ah, got it. I agree, this repo doesn't release frequently, no need for full automation. However I think it would be useful and add a check to CI: if rpm spec does not correspond to the latest git tag, CI should fail. Also it would be useful to add a bash script that updates the spec to the new version. This way, when creating a new release, I'll need to run the script and make a tag. If I forgot to run the script, CI will remind me. |
|
I've created issues: #11, #12 |
|
@twojstaryzdomu BTW could you also take a look at the question in #9 (comment) ? |
2 participants
Produces rpms files required by the
roc-toolkitspec.