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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
