On 2013-01-03 08:41, Reinhard Tartler wrote: > On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst <wou...@debian.org> wrote: >> On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote: >>> - Private dependencies, as they leak to rdeps. When a library uses >>> another library privately this dependency gets linked in directly >>> in all other rdeps, when that library stop depending on that >>> private dependency, all rdeps need to be rebuilt. >> Strictly speaking, if you're only using static libraries this is not >> really true; once you've compiled something against a static library, >> the static library might change in whatever way it sees fit, the >> compiled binary will continue to work, with or without recompilation. > Consider this from the application perspective: Say an application > links against a library libfoo.a. At some point, libfoo decides to > include compression support, and requires functionality from libz. No > problem for the library package maintainer; he just adds a > build-dependency on libz-dev, and uploads the package. At some point > the security team needs to update the application and finds the > package to FTBFS because libz is missing. The solution, of course, is > now to extend the build-dependencies of the application package. > However, this is not obvious and in any case more effort than a > binNMU. > Yes, there are compile-time dependencies for any static library. We do need to track these. In practice we already have a mechanism in pkg-config, but this is (I believe) not properly formalised in Debian.
In the case you mention, if libfoo now depends on libz, adding a build dependency on libz-dev fixes the problem with libfoo.so as it will automatically pull in libz.so However, the packager should _also_ provide a pkg-config file and this will have a list of the dependencies , so LIBS:=` pkg-config --static -libs foo` does the right thing, and the updated libfoo-dev package will include -lz on the libs line. I think we should do the following: (1) pkg-config files for libraries, in particular all those that ship static libs, to be a release goal for jessie. It would be useful / interesting if pkg-config information could be used to generate dependencies for the libfoo-dev package: ie. if libz is _really_ needed for libfoo, then libfoo-dev should depend on libz-dev, to provide libz.a. But this is harder than it looks. Consider the case of netcdf. This ships a libnetcdf.a static library, and this may be used in scientific codes for optimisation as well as "reliability". But in modern terms, libnetcdf, which reads netcdf files, may also accept a URL as well as a filename. In this case, it uses libcurl to retrieve the file, but pulls in a huge trace of packages, from gnutls, ssl , pam packages, psql, msql , etc in order to get authentication. In practice this means I might build my scientific binary with libnetcdf.a static and dynamically link libcurl.so (which may never be called in my actual workloads) to avoid pulling in the whole distro. So recursively pulling in all potentially needed static libs is not an option, but examining all binaries to find what static libs were used to generate it might be problematic. >> This isn't true if you're using a mix of shared and static libraries, of >> course. > mixing shared and static libraries makes the situation no less > complicated, that's true. > > regards Alastair -- Alastair McKinstry , <alast...@sceal.ie> , <mckins...@debian.org> http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e568b3.6070...@sceal.ie
