Bug#54985: debian-policy: handling of shared libraries
Roland Rosenfeld writes ("Bug#54985: debian-policy: handling of shared libraries"):
> The normal situation is, that users have both packages libfoo and
> libfoo-dev up to date, which means, that they are the same version and
> then both packages include the identical file.
Perhaps you run only systems which are up to date with unstable.
However, my experience is quite different. There are costs associated
with continuously upgrading, especially from unstable: constant
change, risk of bugs which take time to diagnose and/or fix,
difficulty of obtaining binary packages in a timely and cost-effective
way, &c. For this reason I like to run most of my production systems
using the current stable release.
However, sometimes I'm hit by a killer bug, or want to upgrade a
particular package to the latest and greatest version. Often it's a
while before I can update to the latest stable, and in the meantime a
security fix comes out, so I need to install a package from the new
stable when my system is still mainly from the previous release.
However, with the current arrangement I can't do that. Whenever I
want to upgrade a binary package I have to update the libraries that
it depends on to at least as recent a version. But, because the
runtime libraries and development libraries must be in version
lockstep, this means I have to upgrade the development package too.
Then, due to further dependencies, I usually find I have to upgrade my
entire development environment, and often including the C and C++
compilers and a whole slew of unrelated tools, to the version from
unstable.
Furthermore, once I have done this on one system it becomes incapable
of building binaries which run on systems I haven't done it to.
This whole thing is just too brittle. What is needed is to decouple
something. The most obvious point to decouple is at the division
between runtime and development shared libraries, because there is
already an interface there - the library ABI - which has usually been
carefully worked out by the library authors to be reasonably stable
and forward-compatible. Furthermore, this is a very simple and easy
change.
(A corresponding change to dpkg-shlibdeps will probably also be
required to get the runtime dependencies right on each rebuild.)
As far as I can tell its only disadvantage is that the archive will
grow by a small amount, and that a small amount of extra disk space
will be used on machines used for development. The extra disk space
used by another copy of the .so file is actually very small compared
to the space used by debugging, static and profiling libraries, of
which nearly all development systems will need at least some.
Ian.
Reply to: