[arch-general] BrlTTY Hard Dependancy on eSpeak

[brent s.]

On 2/13/19 5:18 PM, Doug Newgard via arch-general wrote:
> On Wed, 13 Feb 2019 15:25:19 -0500
> "brent s." <bts at square-r00t.net> wrote:
> 
>> On 2/13/19 3:16 PM, Storm Dragon via arch-general wrote:
>>> Hi,
>>>
>>> I'm having some issues with installing brltty. The problem is, it
>>> depends on espeak but I'm using the espeak-ng from community and it is
>>> giving me the unresolvable conflicts problem for that reason.
>>>
>>> I don't think that brltty actually needs espeak at all, and it could
>>> probably be listed as an optional dependancy along with espeak-ng.
>>>
>>> Thanks,
>>> Storm  
>>
>> hopefully polyzen is on this list.
>>
>> polyzen-
>>
>> any reason why you couldn't add espeak to espeak-ng's provides? seems
>> like it's mostly compatible, at least from the interface and lib level:
>>
>> https://github.com/espeak-ng/espeak-ng#espeak-compatibility
>>
> 
> Libs are different, so it's not a drop-in replacement. Provides would be
> incorrect.
> 

really?

the section i linked to claims this:

"The espeak speak_lib.h include file is located in espeak-ng/speak_lib.h
*with an optional symlink in espeak/speak_lib.h*. This file *contains
the espeak 1.48.15 API*, with a change to the ESPEAK_API macro to fix
building on Windows and some minor changes to the documentation
comments. *This C API is API and ABI compatible with espeak.*" (emphasis
added)

granted, we have espeak 1.48.04 in [community], but 1.48.15's been
development status since 2015[0]. i have a hard time imagining that
1.48.04's API and ABI have had breaking changes on what seems to be a
single patch level release, and one four years old at that.



[0] http://espeak.sourceforge.net/test/latest.html

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190213/960adc63/attachment-0001.sig>