Bug#475101: obsolete linuxthreads requirement
Russ Allbery <rra@debian.org> writes:
>> <p>
>> Libraries should be built with threading support and to be
>> thread-safe if the library supports this.
>> </p>
>
> Yes, that's what I'm proposing -- at a guess, you may have misread the
> diff?
>
>>> diff --git a/policy.sgml b/policy.sgml
>>> index bad28af..1ffe148 100644
>>> --- a/policy.sgml
>>> +++ b/policy.sgml
>>> @@ -7225,10 +7225,10 @@ INSTALL = install -s # (or use strip on the files in debian/tmp)
>>> for C files) will need to be compiled twice, for the normal
>>> case.
>>> </p>
>>> +
>>> <p>
>>> - You must specify the gcc option <tt>-D_REENTRANT</tt>
>>> - when building a library (either static or shared) to make
>>> - the library compatible with LinuxThreads.
>>> + Libraries should be built with threading support and to be
>>> + thread-safe if the library supports this.
>>> </p>
Sorry, for some reason I must have completely missed the '-' in your
patch. Then +1 from me.
Hm. There is a small risk that the above will be interpreted to mean
that e.g. pthreads should be enabled if supported by the library, but
that is not always the best solution -- consider if a library supports
native linking to pthreads, nptl, GNU Pth, or no thread library but
require the application to provide mutex callbacks. (We are actually
considering something like that for GnuTLS now, so it is not entirely
hypothetical.) I would argue that the best for debian would be to build
the library in the last configuration. Or can we declare that Debian
only supports one thread package? The problem, of course, is that some
applications will be using pthreads and some will use nptl, and linking
libraries that are hard-coded to use pthreads (or nptl) will not work
well.
However, I suspect the wording above is sufficient, and that it is not a
good idea to go into more details in a policy document. I just wanted
to float this concern, to see if it sparks thoughts in anyone else.
/Simon
Reply to: