[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Looking for help towards my first Debian package (ITP#962603)

On 6/11/20 2:05 AM, Paul Wise wrote:
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:


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)


the repo says public, can you try this link again?



Reply to: