The initial goal of the Arcalibre fork of Calibre was to create an “archival fork” of Calibre, locking in the state of Calibre as of 5 December 2025, with AI antifeatures removed and a reproducible build added.
That turns out, with several days of looking at Calibre’s build system in more detail, to be a bit more difficult than I expected. Calibre is a 500k or so line project, about 10k of which is build support — much of that comes in the form of implicit dependencies on the host environment, such as expecting tools like podofo to be installed, and much comes in the form of C/C++ code like SQLlite and Qt extensions.
Given all that, a natural question is then whether making an archival fork still makes sense, or whether Arcalibre should pivot to deprecating or removing features that impose too high a maintenance version and rearchitecting some of Calibre’s internals to be more easily maintainable. As an example of the latter, it could be worthwhile to extract Calibre’s database model into its own wheel that could then be depended on from either Arcalibre or other tools that want to read from Calibre-style databases.
If we do decide to pivot away from being an archival fork, what features should we keep and which ones should we deprecate or remove? For example, one of the libraries with an implicit host dependency at the moment is pychm, a small Python wrapper around chmlib, itself a library for reading Windows *.chm help files. chmlib hasn’t seen an update since 2009; that’s not a bad thing per se, but does raise the question if it should continue being a dependency. On the other hand, Calibre also depends on html5-parser, which creates libxml trees from trees produced by Gumbo, an HTML5 parsing library by Google. Unfortunately, Gumbo has been deprecated since 2016, and is not recommended for production use. Unlike chmib, though, an HTML parser is very clearly in scope; should html5-parser be kept as-is, or replaced with something like html5ever? More to the point, what criteria should we use in making these decisions?
No, yeah, that makes sense. I think getting Arcalibre to the point where it’s usable from a local Nix environment and then focusing on splitting modules out is probably the best path forward for now. Trying to make a Flatpak for Arcalibre turned out to be an immensely frustrating experience, as existing Calibre Flatpaks are based on tarballs that have a lot of extra stuff vendored in, and that are only available for the latest release — making a Flatpak that is reproducible from the source alone is much harder. Focusing on splitting out modules into wheels that can be built independently should make that a lot easier, rather than committing to the work of making a single monolithic Flatpak.