On Oct 12, 2012, at 9:03 PM, Hans-Christoph Steiner wrote: > > On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote: > >> On 10/01/2012 06:32 PM, Stephen Lombardo wrote: >>> Hello Florian, >>> >>> On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer <[email protected]> wrote: >>>> Okay. Can your fork open unencrypted databases? Are there any symbol >>>> collisions with vanilla SQLite? >>>> >>> Yes, SQLCipher can open standard, unencrypted SQLite databases without a >>> problem and it has the same public API and symbols as vanilla SQLite. Many >>> users take advantage of this today to allow substitution in languages like >>> python and ruby. For example they may build SQLCipher in a separate >>> directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library >>> for use in their programs. >>> >>> I believe this is is the reason Hans opted to alter the library name to >>> libsqlcipher, to ensure there wouldn't be any confusion between the two, >>> but I'll let him comment on that further. >>> >>> Cheers, >>> Stephen >> SQLCipher shares all of the public symbols that SQLite3 has, plus a few >> more related to the encryption. It is a lightly modified version of >> SQLite3. Like Stephen said, its possible to dynamically load the >> SQLCipher library for an app that was compiled against SQLite3 and it'll >> work. Also, when not using encryption, SQLCipher works the same as >> SQLite3 in terms of SQL commands, C API, etc. >> >> To make it friendly to packaging, I've made the library called >> libsqlcipher.so with its own ABI version related to the SQLCipher >> version, then the headers are in /usr/include/sqlcipher so they don't >> get easily confused for the SQLite3 headers. >> >> Are you thinking that this package should replace the SQLite3 package in >> Debian? I suppose that is a possibility. I'm guessing that the headers >> would need to be split up. Right now the SQLCipher symbols are just in >> sqlite3.h, and that header is in /usr/include/sqlcipher. I suppose >> sqlite3.h could be untouched, then the SQLCipher symbols could go into >> /usr/include/sqlcipher.h or something like that. >> >> The question remaining there would be how to represent the ABI >> versions. So far, there is no established ABI versioning scheme since >> SQLCipher has mostly been used on iOS and Android. So that's the good >> news. The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based >> on SQLite 3.7.9. In other words, SQLCipher's release cycle is not >> necessarily in sync with SQLite3's release cycle.
We discussed this a bunch in early October and then the discussion died. I just wanted to check in to see if anyone has any time to green light this packaging approach, or nail down a different way. The discussion ended with the above: me asking for more information on an idea of whether the SQLCipher package could provide SQLite. .hc -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
