On 2015-06-13 14:44 +0200, Thomas Dickey wrote:
> On Sat, Jun 13, 2015 at 11:51:17AM +0200, Sven Joachim wrote:
>> Source: ncurses
>> Version: 5.9+20150516-2
>> Severity: wishlist
>> Control: block 230990 by -1
>>
>> For about half a year ncurses has a "--with-versioned-syms" configure
>> option that enables symbol versioning. We should use this option in the
>> upcoming ncurses 6.0 release and rebuild all reverse dependencies before
>> the Stretch release so that we can switch to the new ABI afterwards.
>>
>> When using this option, quite a lot of internal symbols which are not
>> part of the API are no longer exported, see the attached list.
>> Fortunately according to codesearch.debian.net, very few packages seem
>> to use any of those symbols:
>>
>> - fpc, in fpcsrc/packages/ncurses/src/form.pp, apparently declares
>> _nc_Default_Form and _nc_Default_Field. Probably nobody really uses
>> those, but I don't really have a clue of Pascal.
>
> Probably no one does...
>
> A web search for these with "pascal" shows only this bug report.
> Because of that, I'm inclined to recommend that Debian drop those
> symbols from its package for fpc.
I have opened bug #789091 for that purpose. Note that these symbols
used to declared in the form.h header in ncurses before the 20091107
patch.
> If there is some existing package
> which does use the symbols, we can address that.
>> - libncursesada and haskell_ncurses declare _nc_has_mouse, but only if
>> NCURSES_VERSION_PATCH < 20081122. Prior to that date, _nc_has_mouse
>> was actually part of the API so its removal might break some old
>> programs. This might be a case where the symbol should actually be
>> exported in order not to break the ABI.
>
> To put it in context, the threshold date is right after ncurses 5.7,
> which is a matter of concern for Debian 6...
It is correct that nc_has_mouse is probably not used by any package
currently in the archive, but ncurses is also used by third-party
software. I think the general consensus in Debian is to only remove
symbols (especially those which used to be public) from a library when
the soname is bumped, see Policy ยง8.6.2[1].
Cheers,
Sven
1.
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]