In Gentoo, right now, we have 2 USE flags that are related to SQLite: sqlite and sqlite3. The current behavior is that the SQLite USE flag installs support for any version of SQLite, while the sqlite3 USE flag install support for SQLite 3. People who have sqlite in /etc/make.conf will normally have SQLite 2 and SQLite 3 installed simultaneously, unnecessarily, and will have have SQLite 2 support in some applications instead of SQLite 3. If they want to get rid of SQLite 2, they will have to do some kung fu in /etc/portage/packages.use and can't rely on /etc/make.conf. It has been proposed to change the current behavior by making the sqlite USE flag pull in SQLite 3: http://article.gmane.org/gmane.linux.gentoo.devel/51670 Perhaps we should create a tracker bug to make this transition easier? Reproducible: Always Steps to Reproduce:
Sure. Gather up all the bugs about deprecating sqlite-2 and make them block this one.
I've filled bugs regarding the use of the "sqlite3" USE flag in ebuilds that only support sqlite-3. I don't know what to do with ebuilds that support both sqlite-2 and sqlite-3. Should I suggest that they change the "sqlite" USE flag to "sqlite2" and change the "sqlite3" USE flag to "sqlite"? Should I suggest them do just drop sqlite-2 support? The last option doesn't seem very nice to me.
this discussion you are linking to probably needs a refresh because fillings bugs without a proper plan for action is going to lead to big mess.
The discussion happened a couple of times already and the conclusion is the same: use 'sqlite' for any sqlite version, sqlite 3 being the preferred version. If a package supports sqlite 2 and 3, punt support for 2. It's a bit like the gtk/gtk2 mess.
*** Bug 285562 has been marked as a duplicate of this bug. ***
Please note that all mail-client/roundcube versions currently in the tree support only sqlite2 through PHP's MDB2 interface. Because MDB2 sqlite2 support was dropped in PHP 5.4, and there is no sqlite3 support for MDB2, and the gentoo developers have refused to restore support for sqlite2 via a dev-php/pecl-sqlite ebuild (see bug 396335), there is currently no upgrade path for Roundcube users unless mail-client/roundcube be applied some upstream patches from git which make Roundcube use the PDO interfaces instead of MDB2. I support the decision to deprecate sqlite version 2, but please provide dev-php/pecl-sqlite for the moment to ease the migration for users until packages follow.
(In reply to comment #6) This is a tracker bug, so do not discuss individual packages here, but take it to the related bug. Thanks.
I have no objection to straightening out our situation regarding the sqlite and sqlite3 USE flags, or even making sure that nothing in the Portage tree depends on sqlite-2, but I think that hard-masking or removing the sqlite-2 ebuild itself is a HUGE mistake. The sqlite3 binary cannot read version-2 databases, so having the old binary is the only way to read and/or convert them. Regardless of whether anything in the Portage tree has a build dependency on sqlite version 2, we should still offer the utility needed to interact with older databases. The linked GMANE gentoo-dev message mentions how easy it is to convert a sqlite2 database to sqlite3. Well, that only works if you have the sqlite binary installed. Please remove the hardmask and preserve the old ebuild.