Derek Atkins <[EMAIL PROTECTED]> writes:
> Isn't that done specifically on by the .so version number? E.g.,
> When gnucash is linked against libgsf-1.so.113 doesn't that make
> the dependency explicit on packages that supply that version
> of libgsf-1?
No.
In the particular case, Debian gnucash currently has the following
dependency (using your example).
libgsf-1-114 (>= 1.14.1)
So anything from upstream version 1.14.1 or later will be tolerated,
but nothing earlier.
>> The source package does not have such versioned dependencies except
>> when there is reason to think they are necessary (which doesn't apply
>> in the present cases AFAICT).
>
> Well, we do depend on gtk-2 >= 2.4 and a few other "minimums", but
> configure should specifically test for that.
Yes, though those are build-time dependencies, not run-time
dependencies.
The build-time dependencies are mentioned explicitly in the Debian
source control file, and of course don't mention any specific version
in the case of indirect dependencies (since those aren't mentioned at
all).
There are so many indirect dependencies because gnucash is using
non-Debian libtool, which pulls in lots of unnecessary indirect
dependencies. Use of the Debian libtool would avoid that, but I
haven't had a chance yet to work on makind gnucash function properly
with the Debian libtool.
In the case of gsf (your example), the Debian source control package
specifies
libgsf-gnome-1-dev (>= 1.12.2)
and it does so because when I packaged gnucash 1.9.1, this was
described in the source as the supported version of the library.
But that's not the question you were asking, which was not about the
source package, but about the binary package.
The actual dependencies in the binary package are not copied from the
source dependencies. Instead, for cases like this, the program
dpkg-shlibdeps is run which looks at the actual library dependencies
of the programs, and figures out which Debian package provides that
shared library image. dpkg-shlibdeps then generates information which
is written into the binary package's dependency list. That is, I run
dpkg-shlibdeps when building the gnucash package to determine which
dependencies to write into the binary package. (Of course, this is
all done quite automatically by higher level tools.)
Each Debian shared library package installs a "shlibs" file which
tells dpkg-shlibdeps which dependency to install. In the case here,
that file is /var/lib/dpkg/info/libgsf-gnome-1-114.shlibs, and
contains the following line:
libgsf-gnome-1 114 libgsf-gnome-1-114 (>= 1.14.1)
The first part is the name of the library; the second part is the
soname suffice, and the rest is the dependency to write in the binary
package.
This shlibs file is part of the libgsf package; it is the maintainer
of that library who decides what the dependency inside the gnucash
package should look like. This is the right method, because it is
that maintainer who is responsible for compatibility. By having this
particular sort of shlibs file, he is saying "if you link against this
version, I promise to maintain compatibility with future versions of
libgsf-gnome-1-114, and any older versions with the same upstream
source, but not anything earlier than that."
Looking now at the source for the Debian libgsf package, we see that
it uses the "dh_makeshlibs" program to generate the shlibs file. In
the relevant makefile, we can see that the maintainer of libgsf is
explicitly requesting this behavior by using the -V option to
dh_makshlibs:
dh_makeshlibs -p$(p_libgsf) -V '$(p_libgsf) (>= $(upstreamversion))'
dh_makeshlibs -p$(p_libgsf_gnome) -V '$(p_libgsf_gnome) (>= $(upstreamve
rsion))'
By contrast, the libofx library, which I am the maintainer of, calls
dh_makeshlibs with no extra arguments. This generates a shlibs file
which looks like:
libofx 2 libofx2c2a
And so, any version of the libofx2c2a package will satisfy the
dependency. (The odd name here comes from the transition to a
different C++ compiler ABI.)
And, as a result, the gnucash binary package declares an unversioned
dependency on libofx2c2a.
So, the reason there are so many versioned dependencies here arises
from two sources:
First, gnucash's build process uses a libtool which inserts a lot of
extra possibly unneeded library dependiences in the binary (what ldd
outputs). Debian has its own libtool which doesn't do this, but using
it breaks the current gnucash build procedure.
Second, the Debian maintainers of the libraries gnucash is linking
against are making more conservative compatibility promises. I
believe this is done to simplify the otherwise complex task of
tracking interrelationships between the very large number of gnome
packages.
Thomas
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
