Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
On Tue, Sep 06, 2005 at 01:10:11PM +0300, Eddy Petri?or wrote:
> Hello all,
Good morning,
> - if I add dh_shlibdeps to the build then I have a warning during the
> build of the package - something about misc libs not being defined and
> some nasty errors during installation, but the package installs and
> works, anyway; also lintian reports an unnecessary call to ld
> - if I remove dh_shlibdeps, then the package results in a cyclic
> dependency on itself, but the misc issue disappears; also the ld issue
> is gone
Did you try using the -l option to dh_shlibdeps? I think this is
necessary to allow it to search your package directory for libraries.
My understanding is that the shlibs file is what allows runtime
dependencies to be handled nicely. Check /var/lib/dpkg/info/*.shlibs;
all the libraries you have installed provide a file which allow for a
mapping between a given dependency (the output of objdump -p |grep -w
NEEDED) and a given package name.
> - the compile generates a set of 3 libqingy* files; do I have to make
> a libqingy package, too?
It seems that these are probably not meant to be used by other
applications, correct? Are the 3 files .a, .so, and .so.0, or are
there 3 libquingy-$foo.so files, for 3 different values of $foo?
My understanding is that you should not provide a separate library
package if the libraries are just internal to the program, and are not
meant to be used by others. If they _are_ meant to be used by others
(other developers, and other packages, potentially), then my
understanding is that you should provide a separate libquingy package
(and a libquingy-dev which contains just the libquingy.a, the
libquingy.so => libquingy.so.0 symlink for compilation, and the
quingy.h header).
Are there multiple binaries in your package? If not, then you should
probably just link the library statically into the single binary,
which resolve the whole issue anyway. There was a -mentors thread
about this about 6 months ago.
Could someone else comment on when a separate shared library package
should be used?
Could someone else also comment on how applications should deal with
shared libraries which are not intended to be used by other programs?
One possibility is to put the libraries into /usr/lib/quingy/, and
make /usr/bin/ (/bin/?) quingy a #!/bin/sh script which simply sets
LD_LIBRARY_PATH=/usr/lib/quingy and exec's /usr/lib/quingy/quingy,
which would be the ELF binary itself.
What you probably want to avoid is using the linker's RPATH setting to
do the same. I tried it once myself, and I can confirm that rpath is
highly inflexible.
> - there is a qingy file in etc/pam.d which is not copied in the
> package, although I added dh_installpam; the directory in the
> resulting package is empty and the file in question is not anywhere in
> the package;
Do you have a ./debian/quingy.pam which lists the file? It seems that
this is a special-case way of adding it as a conffile. Make sure that
a conffile is actually what you want (I think it probably is).
> - the application is licensed under the GPL, but the documentation is
> GFDL; I saw that the upstream authors say "free programs need free
> documentation", thus I feel they (only 2 of them) would agree to
> changing the documentation license; what do you suggest I should do?
Contact them and explain your position, if any, or provide pointers to
Debian's take on the issue. Manoj has one such statement, and -legal
surely has many more. Maybe you could suggest a dual license of the
documentation?
> ** I was under the impression I took the source package with myself,
> from home to work.
Huh? The "source package" is a thing defined as the .orig.tar.gz, the
.diff.gz, and the .dsc file. It gets upload to a machine somewhere
such that people (with the appropriates Sources.gz file, and
sources.list entry) can apt-get source quingy. It is also what allows
the Debian buildds to compile the package for the other architectures,
and what satisfies, for example, the GPL's requirement that source be
made available alongside the compiled binaries.
I don't understand your last comment, or how it relates to anything
else:)
Greetings,
Justin
Reply to: