Debianizing YARP

From Wiki for iCub and Friends
Revision as of 11:20, 27 August 2010 by Paulfitz (talk | contribs) (OpenSUSE)
Jump to: navigation, search

Issues thrown up during preparation for Debian packaging will be listed here. See launchpad for the current /debian/* directory. Commonly a project provides a yarp-x.x.x.tar.gz file and a debian.tar.gz file in parallel, that is, if upstream decides to do packaging herself.

Copyright/license

  • All files should have copyrights defined. Also scripts, examples, pictures.
  • Check e.g.: head example/cuda/progs/*.cu
    • Author of cuda stuff is on vacation in Croatia, promises to fix soon.
    • email out to yayarpview author.
    • gtkdemo? still no decision.

Lintian

The current lintian output can be obtained here: http://pastebin.com/XDq0dmLh It is important that the source is "Lintian clean" to be accepted by the Debian community. Feel free to update this link if you remove errors, but make sure you actually build in a Debian sid environment, and do not use lintian from your own OS.

Linking

  • According to dpkg-shlibs there are libs uselessly linked. Just one of them is given as an example, namely libYARP_init linking to all YARP libraries, instead of just libYARP_OS. Find a patch for this specific example at launchpad.

A full report:

dependency on librt.so.1 could be avoided if "debian/libyarp-os0/usr/lib/libYARP_OS.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-sig0/usr/lib/libYARP_sig.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-dev0/usr/lib/libYARP_dev.so.0.1" were not uselessly linked against it 
dependency on libACE-5.7.7.so could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on libpthread.so.0 could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on libYARP_sig.so.0 could be avoided if "debian/yarp-bin/usr/bin/yarpdev" were not uselessly linked against it 
dependency on libACE-5.7.7.so could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it 
dependency on libpthread.so.0 could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it
dependency on libfontconfig.so.1 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libatk-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libgio-2.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libcairo.so.2 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpango-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libgmodule-2.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpangocairo-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libfreetype.so.6 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpangoft2-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it

EXPORT

If I may, I would recommend to use the following EXPORT macro:

 #define EXPORT __attribute__((visibility("default")))

As explained on http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

You can make explicit which symbols to export by using it like this:

 class EXPORT yarp::os::ConstString {

The g++ compiler will need an additional flag in that case: -fvisibility=hidden

Symbols are generated by:

 dpkg-gensymbols -v0.1 -plibyarpos -e/yourfreshlycompiled/libYARP_OS.so -Olibyarposwithless.symbols

But you won't need to generate those symbols yourself, that would then be my responsibility as maintainer. Just update the SONAME if you change header files with the "EXPORT" keyword defined. And the change needs to be an actual change in function name or the deletion of a function. The mere addition of a function does not mean that the ABI is broken.

From version 1.15.8 upwards, dpkg-gensymbols does have c++ pattern type, see its man page, if you have such a recent version (it's on Debian sid, so if you have build before for unstable, you can use something like sudo DIST=sid cowbuilder --login to find out, most manpages online are older). For example, even if _ZThn8_N3NSB6ClassDD1Ev@Base on 32bit architectures will probably be _ZThn16_N3NSB6ClassDD1Ev@Base on 64bit ones, it can be matched with a single c++ pattern:

      libdummy.so.1 libdummy1 #MINVER#
          [...]
          (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
          [...]

The demangled name above can be obtained by executing the following command:

          $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt


OpenSUSE

In case of a .spec file, it is really recommended to respect a -DLIB_SUFFIX=64 cflag. For that append all install targets in the CMakeLists.txt files with ${LIB_SUFFIX} after DESTINATION lib.

 install(TARGETS YARP_init EXPORT YARP COMPONENT runtime DESTINATION lib${LIB_SUFFIX})

The current yarp.spec file can be found at: https://build.opensuse.org/package/files?package=YARP&project=home%3Aannevanrossum

    • LIB_SUFFIX now respected --paulfitz