[Tts-project] Migration from Berkeley DB

[Samuel Thibault]

Hello,

Igor B. Poretsky, le sam. 18 juil. 2026 19:54:44 +0300, a ecrit:
> >>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:
> 
>     Samuel> Sure, but we don't have the choice if we keep just one place
>     Samuel> for the arch-dependent database: we then cannot co-install
>     Samuel> several architectural variants of librulexdb2, since the
>     Samuel> last postinst call would create the database, and only that
>     Samuel> variant of librulexdb2 will be able to use it and others
>     Samuel> won't.
> 
> But rulex-data is a separate package and librulexdb2 doesn't strictly
> depend on it, though recommends.

Ah, indeed, which makes the situation even more tricky :)

It's actually the lmdb-utils architecture that determines the format of
the database, and thus librulesdb2 needs to have the same architecture
as lmdb-utils, to be able to re-read it.

>     >> And making rulex-data package architecture dependent would
>     >> complicate cross-building.
> 
>     Samuel> Which cross-building?
> 
>     Samuel> By "making it architecture dependent", do you mean putting
>     Samuel> the database in arch-dependent paths? This can be encoded in
>     Samuel> the compiled binaries, that's a very common thing with
>     Samuel> multiarch support.
> 
> But in any case it would be necessary to run foreign executable to
> generate the database file during package building, that in turn would
> require additional foreign architecture emulation means, like qemu, for
> instance, thus, build dependencies complication. Or I miss something?

That is it. But that's a common thing to do. And notably on
architectures which can natively run both 32b and 64b variants. Setting
multi-arch tells people they can really run both versions concurrently.

Samuel