On Wed, 29 Oct 2014 at 10:33:32 +0100, Balint Reczey wrote:
> Filing bugs against reverse dependencies to migrate to sqlite 3 would be
> a better start IMO.
5 years later, here is an updated status, using dak (the same tool the
ftp team would use to remove packages) rather than apt-cache rdepends,
so that all binary packages and all dependency types are considered:
> smcv@coccia ~ % dak rm -R -n sqlite
> ...
> Checking reverse dependencies...
> # Broken Depends:
> cl-sql: cl-sql-sqlite
> dbconfig-common: dbconfig-sqlite
> golang-gosqlite-dev: golang-gosqlite-dev
> kannel-sqlbox: kannel-sqlbox
> libdbi-drivers: libdbd-sqlite
> libopendbx: libopendbx1-sqlite
> python-sqlite: python-sqlite
> python-sqlite-dbg
> qsf: qsf
> qt4-x11: libqt4-sql-sqlite2
>
> # Broken Build-Depends:
> libapp-info-perl: libsqlite0-dev
> libdbi-drivers: libsqlite0-dev
> libopendbx: libsqlite0-dev
> python-sqlite: libsqlite0-dev (>= 2.5.6)
> qsf: libsqlite0-dev
> qt4-x11: libsqlite0-dev
These can be classified into three groups:
1. Non-database-specific access layers that have both sqlite 2 and sqlite 3
integration, in separate binary packages:
- cl-sql
- dbconfig-common
- libdbi-drivers
- libopendbx
- qt4-x11
2. Packages that pull in *both* sqlite 2 and sqlite 3 via the same binary
package:
- golang-gosqlite-dev
- kannel-sqlbox
3. Packages that specifically depend on sqlite 2:
- libapp-info-perl (B-D only, for a unit test)
- python-sqlite (Python 2 only, so already considered RC-buggy)
- qsf
Additionally, if I ask dak "what would happen if we removed all the
sqlite 2 bindings from group 1?", we get:
> smcv@coccia ~ % dak rm -R -n -b sqlite libsqlite-tcl libsqlite0
> libsqlite0-dev sqlite-doc python-sqlite python-sqlite-dbg libopendbx1-sqlite
> libdbd-sqlite dbconfig-sqlite cl-sql-sqlite libqt4-sql-sqlite2
> ...
> # Broken Depends:
> cl-sql: cl-sql-tests
> cylc: python-cylc
> dtc-xen: dtc-xen
> golang-gosqlite-dev: golang-gosqlite-dev
> kannel-sqlbox: kannel-sqlbox
> qsf: qsf
> yum: yum
>
> # Broken Build-Depends:
> libapp-info-perl: libsqlite0-dev
> libdbi-drivers: libsqlite0-dev
> libopendbx: libsqlite0-dev
> qsf: libsqlite0-dev
> qt4-x11: libsqlite0-dev
The newly-mentioned packages there are:
* cl-sql-tests: can be ignored, presumably the dependency on its own
sqlite 2 backend would be dropped at the same time the backend is
* cylc: Python-2-only, already removed from bullseye
* dtc-xen: Python-2-only, already removed from bullseye
* yum: Python-2-only, already removed from bullseye
So I think the steps that would be necessary to remove sqlite 2 from
bullseye (or any future release if bullseye is considered too soon)
would go something like this:
* port or remove qsf (popcon inst:9, maintained via NMUs and FTBFS with
a future version of gdbm, so removal seems more likely)
* make libapp-info-perl's unit test use sqlite 3 or a mock sqlite
(in fact it seems like it already does, so perhaps the dependency on
libsqlite0-dev is a mistake)
* for packages in group 1 (libdbi-drivers and similar), ask their
maintainers to remove the sqlite 2 binary package, with a migration path
if appropriate (for example, if a Perl app is configured to use the
sqlite 2 backend, and sqlite 3 can still read and write sqlite 2
databases, then DBI could select its sqlite 3 backend instead)
* for packages in group 2 (golang-gosqlite-dev and kannel-sqlbox), ask
their maintainers to drop the sqlite 2 part, leaving only the sqlite 3
part (possibly with a migration path, as above)
Regards,
smcv
