The unship patch was just merged in mozilla-central in bug 1611386. Marco
On Thu, Feb 6, 2020 at 4:11 PM 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
