Did some more digging on the issue.

Here is a diff between 2 python manifest files. One is stock that was built without sqlite on the system and the other was built with sqlite on the system.

That's it.... All of the in-house python sqlite files are installed by python regardless of whether the stand alone sqlite package is installed or not except for the file above.

If you opt for the stand alone pysqlite package instead of rebuilding python, then all of pysqlite's files get placed in site-packages.

If you "acidentally" rebuild python with sqlite on the system as well as having the stand alone pysqlite package, it doesn't matter then. There is no file conflict and one of them will be redundant, most likely the stand alone pysqlite package....

So. Do what ever makes you happy...

What I've chosen to do on my own build is to lump pysqlite in with the sqlite package. If I ever rebuild python and it links against sqlite, then so what. The extra site-packages in sqlite really won't bother me. I feel it's better to have a difinitive home for pysqlite than to further complicate my build-order/dependency chain...

I could even add a conditional to the python build script which removes that lone file if sqlite is found on the system. Or just check for the file and remove it period... Theoretically, your right back to a stock python package... I didn't diff the actual packages, just the manifest files. So, Dunno.