On Thu, Jan 23, 2020 at 10:05:36AM +0000, Simon McVittie wrote:
> 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:
> 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)
I think the removal of sqlite 2 is really overdue. I've just filed an
RM bug for qsf, shall we bump this bug to RC to drop remaining rdeps
via auto removals if not fixed?
Cheers,
Moritz
