The Depends in debian/control are not the same as the dependencies of
the library file itself (although usually the library dependencies are
automatically translated to Depends using ${shlibs:Depends}). When
linking the library you need to link against libz.so, typically you
would do that like this:
gcc -o foo foo.o bar.o baz.o -lz
when dh builds the library, the linking command of the libzmat.so
file did include the -lz flag (and the linking was successful)
gcc -shared -Wl,-soname,libzmat.so.1 -lz -o ../lib/libzmat.so
zmatlib.o ....
where does "library dependency" get specified in the package, if not Depends?
If you have users who aren't able to do compilation, you can provide the precompiled library and other files in a separate tarball or zip. If you are using github, you can attach those to your release tags.
that's possible. however, some of the file release systems, such as MATLAB File Exchange, only links to the github generated master.zip/release packages. if I remove the mex files from my github folder, users will not be able to run unless they know how to recompile.
I did have a separate github repo for binaries, but it is quite
painful to sync and promote if I have two URLs.
for now, I will simply create a source-only orig.tar.gz file when
I upload my package again.
Since you are upstream, check out our guide for upstreams: https://wiki.debian.org/UpstreamGuide
thanks for the link. I agree that library bundling is a bad thing
only if such library is widely available and frequently updated
such as on Linux, but when you aim to support users cross
platforms (especially those using windows), counting on users to
install all dependencies and successful compile your code is
simply difficult. Bundling lightweight dependencies (with a
compatible license of course) could potentially save lots of time
and trouble. Bundling also avoids a lot of instability issues when
a library decides to make a non-backward-compatible interface
changes (which happens quite often among linux libraries).
anyhow, my opinion is that while admitting bundling is not a best
practice, it is not something that should be forbidden either. If
I can't bundle lz4 source codes (4 files), then I will have to
change my upstream makefile and create a new release.
This repository doesn't appear to be public, but libzmat is definitely the wrong name for the binary package name, it should be libzmat1. It is an acceptable source package name, but if you change the Debian source package name you should probably also change the upstream name. Which upstream name you want is dependent on what you intend to put into the repository, is it just the library (use libzmat) or also other things that use the library (use zmat). You could also put those other things in a separate upstream repository and source package.
here is Boyuan's suggestion (see response to issue#4)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962640#14
the repo says public, can you try this link again?
https://salsa.debian.org/fangq/libzmat
thanks