[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FYI: intent to NMU to fix SDL + static X extension library problem

Branden Robinson <branden@debian.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.


Reply to: