Re: [MoM] Packaging OpenSurgSim
Hi Paul,
On Thu, Jan 22, 2015 at 07:58:43PM -0500, paul@paulnovo.us wrote:
> Ok, so I have created the git repository for packaging OpenSurgSim:
>
> git://anonscm.debian.org/debian-med/opensurgsim.git
>
> And put up an initial commit that includes some of the basic files in
> the debian directory. Please let me know how this looks so far.
Looks good - except that the upstream and pristine-tar branch are
missing. Thus you can not simply git-buildpackage. Did you
git import-orig --pristine-tar <upstreamtarball>
as Debian Med policy recommends? You can do this even now. Please make
sure you push all branches after doing this.
> I did
> get pbuilder setup for sid, and got it to build and run the unit tests
> successfully, but I get an error:
>
> dpkg-shlibdeps: error: couldn't find library libyaml-cpp.so.0.5 needed
> by debian/libopensurgsim/usr/lib/libMultiAxisDev
> ice.so (ELF format: 'elf64-x86-64'; RPATH: '')
Hmmm, just spekulating since I'm lazy and would like to wait for the
branches mentioned above and thus not trying the build: If this lib is
needed I'd expect libyaml-cpp-dev in the Build-Depends but havn't seen
it there.
> and some warnings:
>
> dpkg-shlibdeps: warning: can't extract name and version from library
> name 'libSurgSimDataStructures.so'
> dpkg-shlibdeps: warning: can't extract name and version from library
> name 'libSurgSimFramework.so'
> dpkg-shlibdeps: warning: can't extract name and version from library
> name 'libSurgSimInput.so'
> dpkg-shlibdeps: warning: can't extract name and version from library
> name 'libSurgSimDeviceFilters.so'
Odten you can ignore this kind of warnings of dpkg-shlibdeps but I'll
check once I try the build.
> The error, I am pretty sure is a bug upstream, where the libyaml-cpp
> isn't being "installed" by cmake, I will look into this.
As I said: I would add the lib as Build-Depends.
> But the
> warnings, I have some questions about. I see that libraries are usually
> appended with the version number, is this something I need to do
> upstream or in the packaging? Also, it says it can't extract the name of
> the library, is this because OpenSurgSim is not in the name?
Usuelly dpkg-shlibdeps is doing all needed work and you do not need to
care about this (neither as upstream nor as packager).
> Some of the libraries being built do not include "SurgSim", ie
> libMultiAxisDevice.so. Is it a good idea to have all the libraries
> prepended with the same thing, ie libSurgSim?
I do not think so.
> On an unrelated note, OpenSurgSim is dependent on yaml-cpp,
> unfortunately we have patched yaml-cpp, so we can't use the version in
> Debian (I have been trying to get our changes upstream, but have been
> unsuccessful so far).
I think this is actually a *related* note. Does this "unsuccessful so
far" mean upstream has a problem to integrate the changes or did not yet
released a version which does contain the changes? Its Debian policy do
use the packaged version of libraries if at all possible (=you should
try hard to make it possible).
> To handle this, we use CMake's ExternalProject_Add
> to download our patched source and build it during the OpenSurgSim
> build. This brings up a couple issues, I recall that the debian builds
> should not assume there is a network connection, if this is the case,
Yes, that's definitely the case. You can not download anything at
build time.
> any ideas how to handle this?
If you will not succeede in convincing upstream you could add it either
as quilt patch but this is probably to large. You can a also add it as
debian/<my_patched_source.tar.gz> and unpack it in debian/rules wherever
it is needed.
> Also, I assume this library should be
> renamed to something that doesn't clash with yaml-cpp in the debian
> repositories.
Yes.
> How about libSurgSimyaml-cpp?
I would not call myself gifted in inventing names but I do not see
any problem with this name (rather in the principle to have code
copies but that was discussed above).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: