anlambert
commented
7 years ago Thanks a lot! I will look at it soon.
Is it possible to have the .spec file maintained in any other place than the main repository ? This is typically how packaging for other Linux distributions work (grab the tarball, patch its content if needed then build the package using a control file). Otherwise, I agree with your packaging scheme: tulip and tulip-devel should be sufficient and the doc is quite essential if you want to learn the basics of Tulip and play with its Python API.
olahaye74
Here is the 1st version on a tulip.spec file that can be used to build tulip rpm package on CentOS/RHEL/fedora (suSE and other rpm distros not tested). This version won't work yet with today devel version because not all patches have been merged, but should work provided #23 is fixed. 1/ when doing a release, the final spec file must be in the tarball (not only the .spec.in). this allow to build the package using "rpmbuild -tb tulip-version.tar.gz" rpmbuild is smart enought to build a package if it can find a spec file inside the archive (preferably at root) 2/ in git, a .spec.in could be used with places to put version and release. Note that release number cannot be -dev. The usual trick is to put a "0.1" for dev package so final release can be "1" once the package is not a beta anymore (this spec file deals with that assuming all dev release have the "0-dev" version release). 3/ version numbers cannot contain "_". so version 5_0_1 should be 5.0.1 (handled in provided spec file) 4/ not mandatory, but easier: archive name should be the same as extracted directory name and should be named: tulip-.tar.
ex: tulip-5.0.1.tar.gz should extract to ./tulip-5.0.1/
This allow to ommit the -n flag in spec file %setup and allows to refer to archive with %{name}-%{version}
A File hopefully ready to be generated by cmake: tulip.spec.in.gz Note that it assumes that #23 is fixed (python sitelib and sitearch are at correct place, tulip-config.in is patched for pluginpath, cmake Modules are installed in /usr/share/cmake/Modules/)
this spec file will generate 2 packages: tulip and tulip-devel. If it doesn't make sens to install tulip without devel path, then I would merge all in tulip package. Also some package will provide a -doc package allowing to install the app without the doc (for example on a cluster), but as it is an interractiv app, I assume that the doc is needed, used interactively and tulip will not end up on some cluster nodes).
note: this spec file includes hopefully all BuildRequires: needed to build the package. for the runtime, rpmbuild is spart enought to add automatic dependancies for shellbang, libraries, symbols versions, perl packages, python packages. For the runtime, the only missing "Requires" would be some external commands run by exec. Maybe sphynx-build? doxygen? bash? Just tell and I'll add.