[Tts-project] Migration from Berkeley DB

[Samuel Thibault]

Hello,

Igor B. Poretsky, le lun. 13 juil. 2026 21:21:46 +0300, a ecrit:
> >>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:
> 
>     >> Though, if I understand right, the dump format is designed just
>     >> for transferring data platform independently, isn't it?
> 
>     Samuel> Ah, I missed that mdb_dump is not producing an arch-specific
>     Samuel> binary but an text output. It's platform-independent then,
>     Samuel> indeed. Perhaps it'd be interesting to gzip it, though.
> 
> Just have it done. And placed generated database in
> /usr/lib/freespeech. Is it acceptable now?

Sorry for thinking about it only now, but ideally it'd rather be in
/var/lib/freespeech, to leave /usr essentially read-only with files
installed by dpkg.

>     Samuel> The concern, however, is that the database is currently in
>     Samuel> /usr/share/freespeech which is supposed to have only
>     Samuel> arch-independent data. And to keep the multi-arch property
>     Samuel> we'd have to rather use a multiarch path, so it should
>     Samuel> rather be moved to /usr/lib/${arch}/freespeech
>     >> 
>     >> I'd rather prefer /usr/lib/freespeech to not disturb multispeech
>     >> making its default configuration platform dependent.
> 
>     Samuel> Then it's not multi-arch any more.
> 
> I think, it doesn't much matter in this particular case.

It depends on the use case: people could want to run both 32b and 64b
programs using a TTS. Using speech-dispatcher would decouple the issue,
though.

At any rate, going that way means that

Multi-Arch: same

really needs to be removed from librulexdb2

>     >> By the way, I've received a note that multispeech package is
>     >> marked for autoremoval from testing, and I cannot figure out what
>     >> should I do fo the situation.
> 
>     Samuel> It seems that this mark has disappeared.
> 
> But I did not see a cancellation note, anyway.

There isn't any, indeed.

>     Samuel> It was probably just a dependency that got an issue.
> 
> Yes, but questionable dependence is somewhat indirect.

The dependency path can be quite long, yes.

Samuel