Re: [RFC] Go (golang) packaging
On 2013-01-03 08:41, Reinhard Tartler wrote:
> On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst <wouter@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 , <alastair@sceal.ie> , <mckinstry@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.
Reply to: