Dear Jonas, this is the bug report that you asked me for in <http://lists.alioth.debian.org/pipermail/pkg-multimedia- maintainers/2010-June/010668.html>. To sum up, d-devlibdeps simply prints out the corresponding -dev packages for the libraries that the given shared library is linked against. IMHO this is neither right nor common practice. The "dependencies of development library packages" are not necessarily the -dev packages of the libraries that the package in question is linked to. I mean, if libfoo0 is linked against liba0, libb0 and libc0, then liba-dev, libb-dev and libc-dev are *not* necessarily dependencies of libfoo-dev! Imagine what this would mean for e.g. libavcodec-dev. Things are different for static libraries, though. To find out hard dependencies for shared libraries development packages, you should (1) check which headers are included by the public API, (2) check which libraries are referenced by the .pc files and (3) check which libraries are referenced by the .la files. - Fabian
Hi Fabian, Thanks (again) for your input. I do not understand in what situations -dev packages need not depend on -dev packages corresponding to what packages the library links against. As I see it, this is contained in 1st paragraph of Debian Policy §8.4. Perhaps if you elaborate a bit more on your libavcodec-dev example, I may better understand your point? Kind regards, - Jonas
Am 30.06.2010 13:49, schrieb Jonas Smedegaard: I'll try, although my knowlegde in this subject is also rather limited (i.e. whose isn't?). ;) libraries. I'll try to explain my concern in an example a bit less complex than libavcodec-dev: A shared library "libfoo0" makes use of symbols of another library "liba0" and is thus linked against it. However, in our case libfoo0 does not export (parts of) liba's symbols via its own interface (i.e. it does not reference liba's headers in its own exported headers). That is, if an application "bar" uses symbols from libfoo0 that in turn make use of symbols from liba0 - but bar does not use the symbols from liba0 directly - then there is no need to link bar against liba0. It is sufficient to link bar against libfoo0 which in turn is linked against liba0. As a consequence, the application does not need to build-depend on the liba-dev package. For static linking, however, the situation is a bit different: Since you build the whole of libfoo.a into the bar object, instead of only making bar link against libfoo0, you also have to build the whole of the libraries that libfoo.a uses symbols from into the bar object. In this case you need access to all the static variants of the libraries that libfoo references (in our example liba.a) and thus have to install the corresponding -dev packages, e.g. liba-dev. Back to the libavcodec example: If you want to use libavcodec for en- or decoding of multimedia material, you simply use some of the functions it exports in its header files in the libavcodec-dev package and link your application against the shared libavcodec52.so library. The libavcodec52 library package will pull in all the required codec libraries that libavcodec uses internally, but as an application developer you do not have to care which library libavcodec uses to de- or encode certain types of media. That's why the libavcodec-dev package has no further *dependencies* except for libavutil-dev, of which it uses some symbols in its exported interface, i.e. in its own header files. On the other hand, libavcodec-dev *suggests* some other -dev packages that are/were usefull for static linking, i.e. that need to be built into your application alongside libavdcodec.a in order to work. However, the packages in this list once were hard dependencies until we (i.e. Sam and Loic IIRC) decided to not support static linking in this form anymore and demote them to suggests a few years ago. The list has not been updated since then, though, and nobody has complained so far. ;) The difference between both scenarios is also well displayed by the different fields Libs and Libs.private in .pc files. I don't know if .la files also do this distinction, but there is a similar field in them called dependency_libs. I hope I was able to bring some light into this subject. However, I will not claim that everything I wrote here is perfectly corrent. ;) - Fabian
retitle 587612 d-shlibs: bogusly considers private symbols severity 587612 wishlist thanks (bcc'ed control@) account, not all symbols embedded in the shared library. I agree, that d-shlibs do not fully automate dependency resolving, due to this. I do consider more of a wishlist item than a bug, however: As the long description says, d-devlibdeps only *tries* to list the development library dependencies - i.e. it is a helper tool which might need some tuning in each use case. If you have ideas to automate the process of skipping private symbols, they are obviously quite appreciated. Even as-is I find d-shlibs quite useful, also for packages that might need some custom "silencing" (e.g. using the --override option), as it helps reveal some dependencies that might be missed with fully manual routines. I have now lowered severity and retitled according to my understanding of this issue. Please do clarify if you disagree with the judgement - or if perhaps you feel that I still didn't properly understand your point. Kind regards, - Jonas
Am 30.06.2010 15:25, schrieb Jonas Smedegaard: Yes, I think you summarized it in one sentence. ;) bother me, I just filed it because we discussed about it. However, I think the bug title was appropriate nevertheless: d-devlibdeps only *tries* to list the development library dependencies, but it misses the point in doing so. It only suggests way more -dev packages than really necessary. No, I agree with you and believe you have understood what my initial discomfort with d-devlibdeps was all about. - Fabian
You mind find the following article interesting: http://np237.livejournal.com/24424.html - Fabian
That is indeed a nice approach! When/if it emerges officially in Debian, I will strongly consider deprecating d-shlibs. Due to the approach chosen by Josselin of getting it included in debhelper rather than provide it as a separate tool, it will however take quite some years before d-shlibs gets obsolete, as backporting debhelper is quite a pain (in my experience, or at lest it used to be back in the Etch era when I last struggled with it). - Jonas