The package does depend on dev-python/pysqlite:2 but not on Python implementation USE=sqlite. The pysqlite package is no longer maintained and compatible with Python 2 only; while the builtin 'sqlite3' module is basically a maintained clone/fork of pysqlite. If the package actually imports pysqlite2 unconditionally, please check whether it wouldn't work with the builtin 'sqlite3' module as well. If it does, upstream should probably fix the package to import 'sqlite3' *at least* when 'pysqlite2' is not available. If it doesn't, please let us know and we will know that pysqlite needs to be kept in the tree. If the package simply supports 'sqlite3', please let us know or update the deps. However, the latter is unnecessary since the 'old' Python eclass doesn't provide a proper way to do this, and we may decide to drop pysqlite entirely after getting feedback for the packages depending on it.
This one imports 'pysqlite2' only. Need to investigate if it works with sqlite3 as well.
I have tested the package by setting up sqlite3 db as README states and running the test script from sources. I have been able to get it to work successfully with python2.5 and 2.7, both with pysqlite2 and sqlite3 modules. For testing, I have replaced the: from pysqlite2 import dbapi2 as sqlite line with: import sqlite3 as sqlite Therefore, the package needlessly pulls in and uses external pysqlite2.
Ebuild fixed. Can you report it upstream, please?
From my understanding, because pysqlite has been removed, and the ebuild already replaces the pysqlite import with sqlite3 import, this bug is fixed?
(In reply to Michał Górny from comment #3) > Ebuild fixed. Can you report it upstream, please? There's been no upstream commit anymore since 2013. No point.
