Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 249418 - dev-db/sqlite-2 deprecation tracker
Summary: dev-db/sqlite-2 deprecation tracker
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Arfrever Frehtes Taifersar Arahesis
URL: http://article.gmane.org/gmane.linux....
Whiteboard: Pending removal: 2016-02-02
Keywords: PMASKED, Tracker
: 285562 (view as bug list)
Depends on: 251388 251392 251393 251394 251395 251396 251397 251399 251401 251403 251405 251406 251408 251409 408829 408831 408835 530176 535844 548658 548670 548672 550048 570652
Blocks:
  Show dependency tree
 
Reported: 2008-11-30 19:56 UTC by Henrique Rodrigues
Modified: 2016-02-20 17:24 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrique Rodrigues 2008-11-30 19:56:53 UTC
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:
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-12-01 22:08:22 UTC
Sure. Gather up all the bugs about deprecating sqlite-2 and make them block this one.
Comment 2 Henrique Rodrigues 2008-12-18 11:50:20 UTC
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.
Comment 3 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-12-19 13:45:02 UTC
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.
Comment 4 Santiago M. Mola (RETIRED) gentoo-dev 2009-03-07 12:04:26 UTC
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.
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2009-09-19 13:17:53 UTC
*** Bug 285562 has been marked as a duplicate of this bug. ***
Comment 6 Jaak Ristioja 2012-08-24 05:18:23 UTC
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.
Comment 7 Ole Markus With (RETIRED) gentoo-dev 2012-08-26 07:19:59 UTC
(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.
Comment 8 Dani Church 2016-01-18 22:52:32 UTC
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.