A friend of mine recently wished to build PHP with pdo-sqlite ( sqlite3 ), but not plain old sqlite (sqlite2), which he tells me is totally possible after having hand built php many a time. Unfortunately, the Current USE flag scenario assumes that if you want PDO-Sqlite, you obviously want sqlite on its own too, which is not necessarily the case. The Suggested Reccommeded way of providing this would be pdo?( pdo-sqlite?( =dev-db/sqlite3 ) ) alternatively, at the very least, it would be nice to have sqlite & sqlite3 flags like many other packages in portage, but how you would implement that option in a non-confusing way would be hard, ( and yes, php already has a long enough USE flaglist .. its a shame the PDO-PECL modules are unmaintained and going away ) Reproducible: Always
Sorry, we are not adding yet another use flag to php (which would be completely inconsistent with the way other PDO stuff is handled). Either you want sqlite support or you don't.
I think you missunderstand. "Either you want sqlite support or you don't." USE="sqlite" enables SQLITE2.x USE="pdo" enables just PDO USE="sqlite pdo" enables SQLITE3.x(via pdo) and SQLITE2.x There is no conditions which permits the sole installation of just SQLITE3.x via PDO. Sqlite2.x and Sqlite3.x are incompatible. Keep in mind that USE="sqlite" pulls only sqlite2.x as a dep, and USE="sqlite pdo" pulls sqlite3.x _and_ sqlite2.x as a dep, not overly clear , and inconsistent with many other packages in portage ( qt, rails , ekg , pdns , metasploit , dspam, libgda, cl-sql, apr-util , sqliteodbc, opendbx, libdbi-drivers, hk_classes, kannel ) and that for a large number of packages, the USE flag 'sqlite' throughout portage specifically mean 2.x , and in cases where things support both, its generally clarified by the added USE flag 'sqlite3' For most users, I would imagine adding sqlite3 support to php would be non-intuitive to suggest USE="sqlite pdo" to get it, when USE="sqlite" gives them the sqlite2 ( which they don't want ) [ normal ][ pdo ] Mysql | x | USE = "mysql" Mysql | x x | USE = "mysql pdo" Mysql | x | NOT POSSIBLE pgsql | x | USE = "postgres" pgsql | x x | USE = "postgres pdo" pgsql | x | NOT POSSIBLE sqlite2 | x | USE = "sqlite" sqlite2 | x x | INVALID SQLITE 2 NOT AVAILABLE AS PDO sqlite2 | x | INVALID SQLITE 2 NOT AVAILABLE AS PDO sqlite3 | x | INVALID SQLITE 3 NOT AVAILABLE WITHOUT PDO sqlite3 | x x | INVALID SQLITE 3 NOT AVAILABLE WITHOUT PDO sqlite3 | x | USE = "sqlite pdo" the only inconsitency I see here is what one must do to enable given features. At the very least you could make USE="sqlite3 pdo" enable sqlite3 pdo ie: pdo?( sqlite3? ( =dev-db/sqlite3 ) ) which would install sqlite3 support without sqlite2 support, instead of having sqlite doing voodoo magic where we have to guess what it does or look in the ebuild source code :)
Once again - we are not adding more flags to php, making the thing inconsistent with handling of other PDO stuff (like mysql and postgres) and generally making the eclass even more complicated.
