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.

~ lina

On Mon, Feb 10, 2020 at 6:22 AM Marco Bonardo <> 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:
> 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
>, 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 mailing list

Reply via email to