> If you think making a distinction between the SQLite package and the > libsqlite package is pedantic - I don't have a problem with that.
I think that is not only pedantic - it is also inaccurate. There is no SQLite package, nor is there a libsqlite package, in the bigger+ world. From http://www.sqlite.org/download.html I can download the following pieces: sqlite3-x.y.z.bin.gz (for Linux, likewise for OSX and Windows) tclsqlite3* (Tcl bindings - clearly irrelevant here) sqlite-x.y.z.so.gz (for Linux, likewise for Windows) sqlite3_analyzer-x.y.z (also clearly irrelevant here) sqlite-amalgation-x.y.z (amalgated sources) sqlite-x.y.z (complete sources, in tar.gz and .zip) So there is no SQLite download, nor is there a libsqlite download. I don't know what specific packages you are talking about - probably about the way your Linux distribution choses to package things. > Fact > is that none of the packages are required for using sqlite3 with Python > - they are only required when you want to compile Python yourself or > when Python uses the shared library. So the shared library *is* required (as that is the typical way in which SQLite is built) > And even if you want to compile Python yourself, SQLite doesn't have to > be _installed_. You simply can dump the files wherever you like and > point Python to it. This is often necessary on a machine where you > cannot install anything to the default locations because you don't have > admin rights. And that is nit-picking. You don't have to do the "make install" step, but I would suggest to do that, anyway, even on a machine where you don't have admin rights. You just pass --prefix to the configure of the amalgamated sources. This puts sqlite nicely into bin, include, and lib directories, so that Python's setup.py can find it easier. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
