Add rpkg/copr support #69
Conversation
| @@ -1,4 +1,4 @@ | |||
| AC_INIT([rt-app], [m4_esyscmd_s([git describe --tags HEAD])], [[email protected], [email protected]]) | |||
| AC_INIT([rt-app], [1.0], [[email protected], [email protected]]) | |||
There was a problem hiding this comment.
Adding rpkg/copr is a good idea
but is there a way to keep both mechanism running correctly ?
It was convenient to get the sha1 for intermediate build to know which version a rt-app binary is based
There was a problem hiding this comment.
So, I'm pretty new to the rpkg/copr thing, but AFAIU the problem with calling git describe is that rpkg creates a temporary out-of-git-tree copy of the source to build them and create rpms. So git describe doesn't work in this case.
Now, I'm not sure if this is a problem for rpkg local only (I used that before creating the project on copr to test the build process) or also if copr would have problems with that.
In any case, I was wondering if we shouldn't actually "standardize" the release process. We are still at v1.0 and lot of stuff changed and was added after that?
There was a problem hiding this comment.
Yes. We might need to tag a new version
And more generally speaking release some "stable" version more often
May be it's worth checking what the other package are doing in this area. Imean in order to get some details about sha1 when want to use "dev" branch
Ca, we consider that the rpkg/copr will be used only with tagged version ?
There was a problem hiding this comment.
Ca, we consider that the rpkg/copr will be used only with tagged version ?
Makes sense to me.
So we could
- create a devel branch out of current master
- apply the patch removing git describe only in master
- tag master as.. 1.1 or 2.0 (updating configure.ac accordingly)
- use master for copr (and a debian equivalent in the future?)
- point people to devel for further development and merge in master feature by feature
Do you think it might actually work? :-)
There was a problem hiding this comment.
yes that's seems to be a good way of working
There was a problem hiding this comment.
In the past I've got a chance to use the "gitflow" branching model described here:
https://nvie.com/posts/a-successful-git-branching-model/
and I've found it quite useful. IMO it's pretty close to what @jlelli suggests and I think it could fit for an improved release process for rt-app.
There was a problem hiding this comment.
Nice! Yes this should work.
@vingu-linaro we might act on this by creating a PR that modifies README or points to a doc that states how development and release will be done from now on. Can do that.
Once we have that I can rebase this accordingly...
OK?
Remove git usage from configure.ac, so we can successfully call autoreconf when building sources outside the git tree (e.g., when using rpkg). Signed-off-by: Juri Lelli <[email protected]>
Add a .spec file so that rpkg can be used to build rpms. Signed-off-by: Juri Lelli <[email protected]>
Adding support for copr build and distribution as rpm package might help attract users that don't want to mess with building from sources.
This PR will make the following possible:
https://copr.fedorainfracloud.org/coprs/juril/rt-app/