Repository navigation
Project is insufficiently renamable from "sqlite" to "sqlcipher" #607
Description
Hello, there are many references to "sqlite" in the software,
Line 11 in 810db22
I understand that sqlcipher is a near-ABI-compatible soft fork of sqlite, leading to many internal instances of sqlite that might be difficult for you to automatically rename, but unfortunately, the instances of sqlite are polluting outwards into distributions of the software and conflicting with the file names of the upstream files in the sqlite packages in the same distributions.
This has led to the need for many distributions to modify the files of the sqlcipher software post-installation in a convoluted way, including but not limited to:
and unfortunately, I am struggling with this problem and the need to manually script renaming the files to avoid conflicts is frustrating to handle in my distribution's build framework.
There is an option libsqlite3.DLL.basename that can be set to sqlcipher, to rename some of the files successfully,
Line 1114 in 810db22
However, it only renames these specific files:
What libsqlite3.DLL.basename=libsqlcipher does
| before | after |
|---|---|
| libsqlite3.so.3.53.3 | libsqlcipher.so.3.53.3 |
| libsqlite3.so.0 | libsqlcipher.so.0 |
| libsqlite3.so | libsqlcipher.so |
it does not rename these specific other files that are also installed alongside libsqlcipher.so into the distributed package:
sqlite3sqlite3.hsqlite3ext.hsqlite3.pcsqlite3.1.gz
I believe that providing one or more additional options alongside libsqlite3.DLL.basename that could be used to preemptively rename the rest of the conflicting files to sqlcipher* instead of sqlite3* would be very helpful for all future distributions of sqlcipher and also for future updates to all of the above preexisting distributions, to adopt the new variables and dramatically simplify their build scripts.
Activity
sjlombardo commentedon Aug 17, 2026
Hello @robertkirkman - Thanks for getting in touch about this. The list of distributions is helpful for context.
One of the major concerns here is that we try hard not to stray too far from the upstream SQLite build system. We made the mistake once before of patching the build system, renaming resources, etc, and it caused no end of trouble. We were only able to step back from that undesirable state in 4.7.0. One of our major goals, including with the upcoming SQLCipher 5 release, is to significantly reduce upstream differences, not add more.
I would also like to reference an in-depth discussion that took place in ticket #488. Despite the fact that the title is related to SONAME, some of the later discussion there specifically deals with renaming, OS packages, etc, and is very relevant to this topic. Specifically, the comment I added on 2025-03-26 includes almost all of the background history for this project, as well as the details of the upstream realignment I mentioned earlier.
Additionally, Debian's approach of relocating headers under a separate directory (placing them in /usr/include/sqlcipher to avoid collisions without renaming any files) might be helpful in your case as well.
Once things free up a bit more we may consider potential build options further.
robertkirkman commentedon Aug 22, 2026
I have created this in order to work around my problem,
if this is the type of change that another distributor would like to use, then maybe it could be revised to only activate when a build flag is passed and not modify the default behavior, then submitted as a PR either to sqlcipher, or to sqlite to then be inherited by sqlcipher.