spec file to generate rpm package #26
Comments
|
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. |
|
Many opensource software sill ship with a spec file and/or a debian directory. This packaging is generic and there after, each distro will update/change it if needed. This helps a lot being adopted by distros or 3rd party repositories. |
|
Seems better to maintain the packaging resources inside the Tulip source tree indeed. I will try to test the rpm builds asap. But I will have to find a way to include the dynamically generated tulip.spec file inside the source tarball. I should manage to do it using CPack I think. Adding a new TravisCI job to build and test the rpm packages should also help for the maintenance. |
|
Packaging for CentOS 6/7 is now functional, see anlambert#1. |
|
Seems correct, though I won't have time to test before a few weeks. |
QOpenGL module is marked as deprecated since a while now so it is time to remove its use from the Talipot codebase and promote the use of QOpenGL* classes directly integrated in the QtGui module. The big difference between QOpenGL and QtOpenGL from Qt5 is that all rendering is performed in framebuffer objects, there is no more direct rendering in the underlying os windows with its own OpenGL context. Talipot OpenGL rendering also follows that idiom, all renderings are performed offscreen using a shared OpenGL context. This also means that there is no more QGLWidget as viewport for QGraphicsView. Talipot OpenGL scene are now converted to QImage in order to display them using the default Qt raster rendering engine. This should fixes the numerous rendering glitches observed on MacOS. First thing observed after the migration is a consequent performance boost in OpenGL rendering when using an Intel GPU on a Linux host machine (especially when selecting elements, it is now 10 times faster on debian stable).
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.
The text was updated successfully, but these errors were encountered: