Bug 2291157

Based on the SQLite docs [1] it is disabled for backwards compatibility, but the feature was introduced in version 3.7.7 (2011-06-23), which is very long time ago. It also shouldn't affect correctly working applications even if they don't use the URI filename, as it only expects URI filename if the 'filename' begins with 'file:'. So as long as the application doesn't use db file starting with that string, which I (and the docs) suppose not it should be safe to enable globally.

On the other hand I haven't found other distributions that would do such step apart from the Void Linux you mentioned. Arch Linux for example doesn't set the flag either. Also I have tried the example code from libsqlite3-sys rust SQLite bindings [2] (which I suppose is what you meant) and they do work with sqlite-devel installed. Do you know of any specific code or reproducible steps to cause it to 'not function properly' without the '-DSQLITE_USE_URI=1' flag?

Furthermore based on the aforementioned SQLite docs it is possible to enable use of URI filenames even in code at runtime, which I would suspect to be preferable way if upstream doesn't enable it by default either? And if some tool/library wants to use the URI filenames it might be better to use this option to enable it using `sqlite3_config(SQLITE_CONFIG_URI,1)` as that would solve the problem even for users that use distribution/version without the flag present during compilation. Alternatively there is also this option "...URI filenames can be enabled for individual database connections by including the SQLITE_OPEN_URI bit in the set of bits passed as the F parameter to sqlite3_open_v2(N,P,F,V)." [1]

I am open for more discussion on this topic especially if there are more applications/libraries that need this flag enabled. I am also curious why not to use the aforementioned runtime config options when application uses URI filenames and if there are any reasons not to use it - which could warrant global enablement of the URI filenames with the flag.

[1] https://www.sqlite.org/uri.html
[2] https://crates.io/crates/libsqlite3-sys

The place where I was hitting this issue was with `sqlx-sqlite` crate and when running the `atuin` testsuite. I have managed to track it down to a "bug" in `sqlx-slite` where they only set `SQLITE_OPEN_URI` occasionally [1], but they implicitly set it to URI format without setting the appropriate flag [2]. I am opening a PR to fix it upstream. Most of these issues are due to the rust packages primarily testing and supporting the bundled sqlite interface which enables this option and these issues fly under the radar. 

> which I would suspect to be preferable way if upstream doesn't enable it by default either?

Slightly difficult because the downstream package (atuin) prefers not to support such fixes to upstream issues (sqlx), and getting access to the runtime config would be tricky without sqlx supporting that as well. 

[1]: https://github.com/launchbadge/sqlx/blob/1388fc8acc07b41ab38f4dc096f03ba9c7b851f8/sqlx-sqlite/src/connection/establish.rs#L107-L114
[2]: https://github.com/launchbadge/sqlx/blob/1388fc8acc07b41ab38f4dc096f03ba9c7b851f8/sqlx-sqlite/src/options/parse.rs#L18-L23

The problem is that many different (and very important) packages like dnf depend on the SQLite package so it is preferable to not include changes that could potentially be breaking. With this change the potential for such break isn't necessarily high, but the reason why introduce this change shouldn't be just to fix a bug in one of the packages (in this case not even a package). As you have already made a PR to fix the bug in sqlx (and also that application is the reason why atuin has the problem in a first place since it has sqlx as a dependency) it would be better to wait for a merge rather than modify default SQLite behavior and potentially break something that depends on it. Especially since we generally do not update SQLite in an already released versions of fedora for exactly the same reason, so at best this would land in rawhide/f41 and at that point sqlx might have the PR merged so it wouldn't be relevant anyway.

The problem you are describing would ideally be solved on the atuin side when packaging, but since it is not packaged in fedora that's not an option. I was mainly addressing potentially other packages that would need that flag present and having URIs enabled by default while it also wouldn't be a bug in such package - meaning that there is a legitimate reason why not to use the options I mentioned before, to use URIs with them not being enabled by default, and it's not an oversight like in case of sqlx.

I will be leaving this open for now, potentially there might be a package/use case where this would be worth enabling, but I don't think it's wise to do so for just sqlx.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Closing as no new usecase for this feature was found in the meantime.

If there is a new usecase for this feature feel free to reopen/file a new issue.

Mentioned usecase is to fix a bug in a software which is not even packaged in fedora.