Thank you very much for sending this out, Marco! I completely agree with your analysis: allowing system SQLite complicates things for us, and introduces many sharp edges without benefitting our users. With packaging conventions changing, it makes even less sense to keep around. I fully support its removal.
Cheers, ~ lina On Mon, Feb 10, 2020 at 6:22 AM Marco Bonardo <mbona...@mozilla.com> wrote: > The Storage support team intends to remove support for building > Mozilla-based applications using the system provided SQLite library on > Linux (--enable-system-sqlite). > > > > When: After the next mozilla-central merge to Nightly 75, February 10th. We > plan to unship support during the 75 cycle. > > > > Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1611386 > > Why: > > 1. > > We have limited resources available to us. Developing new features that > touch SQLite low level APIs have often required additional resources to > ensure system SQLite keeps working; we are at a point where we can't > afford > those development costs. > 2. > > We had bugs due to it and the most recent of which, tracked in > https://bugzilla.mozilla.org/show_bug.cgi?id=1607902, is due to a > mistake we made in relying on some Sqlite internal details. The result > of > that, due to supporting system Sqlite, is that we requested the Sqlite > team > to undo some code improvements in a .1 release, and, in spite of that, > older Firefox versions on a specific new Sqlite version will crash > forever. > We don't want to be in this situation where the Sqlite team can't > improve > their product freely. > 3. > > There is risk of losing users due to the kind of crashing bugs this can > cause, because not everyone would be able to connect the misbehavior > with > the update of an external library, that may have been updated along with > other packages updates. And downgrading Sqlite may not be an option if > another software requires the new version instead. > 4. > > For quite some time we ended up enforcing our Sqlite preferences onto > the system library (things like ‘secure_delete’ or ‘fts’, for example); > addressing those cases requires time and resources. We don't want to > enforce our specific choices. > 5. > > Our Web Storage team will soon start working with Sqlite encryption, in > a way that may not be compatible with system Sqlite. Again, having to > cope > with the system library would mean a lot of additional effort, and more > requirements for system Sqlite that may not be well digested. > 6. > > We have our own custom memory allocator, and hooking it up has > complications we'd prefer to avoid, if possible. > 7. > > The benefits of using system SQLite so far have been minimal. We wanted > to be good citizens by sharing as much as possible with the system, as > it > was common practice. Today the historical packaging strategies on Linux > systems are evolving with the introduction of new packaging systems > (Snap, > Flatpak, for example) that changed the relationship with dependencies by > packing them up with the main application. > The remaining benefits (e.g. package size, memory) are negligible on > today's hardware. > The security benefits we get because the system Sqlite may be more > up-to-date are minimal, because we don't expose Sqlite to Web content, > nor > to add-ons. Additionally, we actively track and test every new Sqlite > release and apply them as soon as possible. > > > > Thanks, > > Marco > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
