Re: FYI: intent to NMU to fix SDL + static X extension library problem
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> On Sun, 07 Oct 2001, Philippe Troin wrote:
> > For reference, which says:
> > *** begin quote
> > In general, libraries must have a shared version in the library package
> > and a static version in the development package. The shared version
> > must be compiled with '-fPIC', and the static version must not be
> > (source files will thus typically need to be compiled twice).
> >
> > In some cases, it is acceptable for a library to be available in static
> > form only; these cases include:
> > * libraries for languages whose shared library support is immature or
> > unstable;
> > * libraries whose interfaces are in flux or under development (commonly
> > the case when the library's major version number is zero, or where the
> > ABI breaks across patchlevels);
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> > * libraries which are explicitly intended to be available only in static
> > form by their upstream author(s)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Either restart the flamewar with upstream XFree86 about this, or leave it
> alone. They want it static, we will ship it static.
Not all upstream requirements make sense. We routinely override
upstream choices.
> > *** end quote
> >
> > ...and which I disagree with.
>
> It's Debian policy. It matters not that you disagree with it, unless you
> are going to do something actually constructive about it (such as requesting
> it to be changed based on strong technical reasons). Otherwise, please do
> not waste time and bandwidth.
Well, Mr Robinson asked for opinions about his changes to libsdl, and
I gave my input. I would not call that a waste of time and bandwidth.
As far as the technical reasons for shipping some X libraries as
static libraries only, Mr Robinson quoted the description for
xlibs-dev, that I will repeat here:
Description: X Window System client library development files
xlibs-dev provides static versions of the libraries provided in xlibs, as
well as several libraries that do not exist in shared object form for
various reasons (such as the fact that their API's have not stabilized, or
that they are deprecated). Header files and manual pages are also
provided.
Mr Robinson's argument (correct me if I'm wrong) is that the XFree86
project (upstream) prefers to have these libraries shipped as static
libraries (because "their API's have not stabilized, or that they are
deprecated"). I would argue that packaging is about overriding the
upstream decisions with Debian policy.
Here is why I think that the policy is wrong and why I still maintain
that shipping static-only libraries and "fixing" the SDL libraries are
a bad idea:
A. Shipping static-only libraries is a bad idea because:
1. It requires libraries users to know all the static libraries
which are referenced in the shared libraries they're using.
eg: if libfoo.so use libXxf86dga.a internally, all programs
that link with libfoo.so will also have to link if
libXxf86dga.a, even if they do not use libXxf86dga.a
services or APIs.
In my book, this is bad.
2. In case of critical problems (like security issues), all the
packages linked with a faulty static library need to be
recompiled, versus only the shared library package.
3. Dependencies are not tracked: if a package X is linked against
static library libY, then it does not appear in its
dependencies (although this is mitigated because of
Source-dependencies these days).
B. "Fixing" the SDL libraries is bad because:
1. We introduce "Debian-specific" flags (--library-libs).
2. We're supposed to close to a freeze, and the proposed fix
requires recompiling a lot of package (versus recompiling X
and 3 libsdl source packages).
As a final note, the policy used to be very strong about shared
libraries: all libraries had to be provided as both static and dynamic
until August. The initial amendment mentioned relaxing the
shared-library clause in light of languages which did not support
shared libraries, or for "special" libraries (like libgcc.a and
libc). From the policy, one of the three items which can be used for
not shipping shared libraries:
> > * libraries for languages whose shared library support is immature or
> > unstable;
The initial intent of the amendment has been quite changed in the
final version, when the two other reasons were added, and maybe we
should revisit that.
Phil.
Reply to: