rpm package about aseba HOT 13 CLOSED

As ETH supports fedora as the official Linux version, I am willing to give rpm a try for 1.3.1, anyway it cannot be as ugly as Debian packages... After having a quick look on the net, it seems it is not. We could then try to build on SUSE open build service.

Any advice/good place to look for tutorials on how to create spec files? I have found http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Creating_a_Basic_Spec_File.html until now.

from aseba.

have a look here: https://fedoraproject.org/wiki/Packaging:Cmake for the cmake-specific information

But you will need to package dashel first.

from aseba.

Once done, I would like to store the .spec file in the git tree, is there a best-practice directory to put it to? Maybe rpm/?

from aseba.

well, no. There is no "best-practice" as most of the time, distributions keep the spec file outside of the package in their own svn/git repository.

from aseba.

I've built SRPMS and x86_64 RPMS for aseba, enki, and dashel on my Fedora 20 system and added them to the download page. [Edit: removing obsolete link to Google Drive files].

The enki and dashel packages include patches required to build them as shared libs and install those libs in /usr/lib64 instead of /usr/lib. I'll try to get pull requests together for those changes soon or you can access the patch files by installing the SRPMS.

BTW, for the aseba package, I only install the files that are installed by the debian package. Doing 'make install' normally installs a bunch of other files including extra executables and libs/headers needed to build the executables. Can/should the CMakeLists.txt files be changed to not actually install those files?

from aseba.

Hi Dean,

Thank you very much for your contributions. I would be happy to apply your patches upstream to Enki and Dashel.

About the Aseba package, yes "make install" also installs files required to use Aseba as a library. I understand that you would prefer it to install only the user part of Aseba. I do not know if there is a clean way to have something like "make devinstall" with CMake, maybe with an option?

So you packaged 1.3.1, not 1.3.2rc?

from aseba.

I think the make install is correct, the .spec file should simply split the binaries from the development headers and provide a -devel package.

from aseba.

I packaged the 1.3.x branch from github as of a couple days ago (which I assume is 1.3.2rc). The "-1" part of the package name is the RPM release number. Packagers are suppose to bump that whenever the spec file is modified.

I'll add an aseba-devel package for the other stuff that is installed by "make install". Fedora guidelines seem to indicate that the examples directory should just be copied to /usr/share/doc/aseba-devel/examples in source form. That OK? If not, I think that qt-gui should be renamed to something like asebaqt-gui.

from aseba.

Copying examples to /usr/share/doc/aseba-devel/examples is fine for me.

Could you please upload your packages to https://aseba.wikidot.com/en:linuxinstall? Anyone who is a "member of the site" can upload page. Becoming a member is a one-click process.

from aseba.

Done. I should have thought of that earlier, since I'd made edits before...

I'll work on putting together pull requests for my patches and to add rpm folders with the spec files and a README.

An important note: The RPMS install shared libraries. If you make changes to a library that break ABI compatibility (which is easy to do by accident in C++), you need to bump the library's major version number. It is set via:

set(LIB_VERSION_MAJOR 1) # Must be bumped for incompatible ABI changes

in the CMakeLists.txt file that is in or above the directory containing the library source.

from aseba.

Thanks a lot! I have updated the download page to make your packages more visible: https://aseba.wikidot.com/en:linuxinstall

Dashel should not receive ABI-breaking changes, but Enki certainly will. I will try not to forget to update the library version. That said, I thought the proper CMake command was set_target_properties(${LIB_NAME} PROPERTIES VERSION "${PROJECT_VERSION}" SOVERSION 1)

from aseba.

Your welcome, and thanks for all of your work on Aseba, Dashel, and Enki. My son is really enjoying programming his Thymio. :-)

Regarding SOVERSION, my patch uses:

set(LIB_VERSION_MAJOR 1) # Must be bumped for incompatible ABI changes
set(LIB_VERSION_MINOR 0)
set(LIB_VERSION_PATCH 7)
set(LIB_VERSION_STRING
${LIB_VERSION_MAJOR}.${LIB_VERSION_MINOR}.${LIB_VERSION_PATCH})
set_target_properties(dashel PROPERTIES VERSION ${LIB_VERSION_STRING}
SOVERSION ${LIB_VERSION_MAJOR})

You could bump the SOVERSION without bumping major package version if you wanted to track API and ABI compatibility separately but I figured that would be unnecessarily confusing.

BTW, I just noticed that all the packages I've produced thus far have a bug where they used SO_VERSION (which does nothing) instead of SOVERSION. As a result they require specific versions of each other and need to be updated in unison. I'll get that fixed right away...

from aseba.

As the RPM package is now maintained by @brettle, I close this bug.

from aseba.