Re: FYI: intent to NMU to fix SDL + static X extension library problem
Branden Robinson <firstname.lastname@example.org> writes:
> On Sun, Oct 07, 2001 at 12:50:04PM -0500, Steve Langasek wrote:
> > It's hard enough to deal with such situations as it is (c.f. libdb2 v.
> > libdb3), without creating more such situations against the wishes of the
> > upstream developers.
> Why, having everything always available as a shared library never causes
> *any* problems *at all*...
> libgal12 - G App Libs (run time library)
> libgal13 - G App Libs (run time library)
> libgal11 - G App Libs (run time library)
> libgal7 - G App Libs (run time library)
> libgal8 - G App Libs (run time library)
> libgal9 - G App Libs (run time library)
Yes. So what ? Link everything statically ?
> Anyway, Philippe Troin has a long history of opposing any decision I
> make for sole reason that I have made it (personal animosity),
Indeed, I spend my whole days searching for Branden's communications
and making a point to disagree with him :-)
More seriously, the only email exchange I had with Branden in the last
few months is the discussion about bug #112408, where we happen to
disagree. I guess that's Branden's definition of "personal animosity".
> so I am disregarding his objections for that reason on top of the
> technical fallacies he has upheld to support it.
Can you point out which technical fallacies please ?
> Besides which, his assertion about providing all .a's as .so's is
> contradicted by the Debian Policy I amendment I referenced in my
> original message, which passed without objection once we had it in
> concrete form.
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
* 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);
* libraries which are explicitly intended to be available only in static
form by their upstream author(s)
If a shared version of a library package is not desired and the reason
is not listed above, the maintainer should seek consensus for the
decision on the debian-devel mailing list. In any case, any library
that does not provide a shared version should discuss why in its
package's extended description. If a library is available only in
static form, then it must follow the conventions for a development
*** end quote
...and which I disagree with.
> As usual, Philippe probably didn't bother to read much more than subject
> line before objecting to my proposed course of action.
As usual, Branden use ad hominem attacks to justify his point of view.