From sthibault at debian.org  Sun May 24 17:28:25 2026
From: sthibault at debian.org (Samuel Thibault)
Date: Sun, 24 May 2026 18:28:25 +0200
Subject: [Tts-project] Migration from Berkeley DB
In-Reply-To: <875x4phsuo.fsf_-_@poretsky.localdomain>
References: <aP_q6NnsUNs-yeHc@per.namespace.at>
 <aP_q6NnsUNs-yeHc@per.namespace.at>
 <handler.s.B.1761602283983399.transcript@bugs.debian.org>
 <8733zv1x83.fsf@poretsky.localdomain> <agR7qkeHsrJcMxeD@end>
 <875x4phsuo.fsf_-_@poretsky.localdomain>
Message-ID: <ahMnKT3IRTvJig-1@end>

Hello,

Igor B. Poretsky, le ven. 15 mai 2026 13:25:51 +0300, a ecrit:
> In the process of the rulex package migration I've noticed that the
> rulex-data binary package bearing compiled database is not architecture
> independent anymore in its original form.

Ah...

> Architecture independence of
> data file format is a documented feature of Berkeley DB, but it is not
> the case for LMDB. Thus, we should provide data in some other truely
> architecture independent format or make this package architecture
> dependent.
> 
> For the rulex package I've chosen the first way distributing data as a
> database dump that is loaded by the postinst script. I've implemented it
> in my last commit.
> 
> Is this solution absolutely correct?

Not exactly: this is assuming that the architecture of the installed
lmdb-utils package is the same as the rulex package. Also, the
management of the rulex.db file will remain something tricky to
maintain. It seems simpler to me to make rulex-data arch-dependent.
rulex will then depend on the appropriate rulex-data architecture
version.

The concern, however, is that the database is currently in
/usr/share/freespeech which is supposed to have only arch-independent
data. And to keep the multi-arch property we'd have to rather use a
multiarch path, so it should rather be moved to
/usr/lib/${arch}/freespeech

> And, I think, the similar considerations can be applied to some other
> packages as well. The freespeech package, for instance, migrated to
> GDBM. Unfortunately, I did not find clear explicit declaration
> concerning architecture dependency or independency of its data files,
> But if architecture independency is not clearly declared, I think, we
> should treat these files as architecture dependent.

If we don't know, we'd better stay on the safe side, indeed.

With regards,
Samuel