Bug 1484086
Summary: | SQLite must be downgraded to 3.19 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michael Catanzaro <mcatanzaro+wrong-account-do-not-cc> |
Component: | sqlite | Assignee: | Petr Kubat <pkubat> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | bnocera, jakub.dornak, jstanek, piotrdrag, pkubat, stickster, wilmer5 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-28 11:13:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michael Catanzaro
2017-08-22 16:15:53 UTC
Last year's equivalent bug was bug #1312506 Thanks for the report. I do not think a downgrade to the previous version is necessary here. This should already be fixed for the latest versions of tracker by building sqlite with fts5 by default. I have yet to take a look at f25 if the back-ported security issue fix broke tracker as well and will drop it in case it did. How is it OK to update to incompatible versions of sqlite in a stable version, and expect others to mop up the bugs after it? https://sqlite.org/changes.html says, for 3.20: "Backwards-incompatible changes to some extensions in order to take advantage of the improved security offered by the new pointer passing interfaces:" That should have been enough information to know that this update wasn't suitable for a stable release. I agree that this breakage should be avoidable. On a hopeful note, it's likely that CI efforts in Fedora will allow interested folks to provide integration tests to successfully gate updates like this in the future. Someone would have to write those tests, of course, but just having the possibility is a big step in the right direction. Since the corpus of tests would be iterative, though, maintainers still need to be vigilant about not introducing clearly backward incompatible bits. (In reply to Petr Kubat from comment #2) > I do not think a downgrade to the previous version is necessary here. This > should already be fixed for the latest versions of tracker by building > sqlite with fts5 by default. That seems fine. We're primarily concerned with avoiding this situation in the future, since it's a high-impact bug that has occurred twice now. Can you confirm that you'll be more careful with checking for incompatible changes in future sqlite updates, particularly fts5 changes? If so, I think that's all we need here. >How is it OK to update to incompatible versions of sqlite in a stable version, and expect others to mop up the bugs after it? I am not saying it is OK to do this and it is obviously a failure on my part to check the ABI/API compatibility properly (and I am sorry for that). However downgrading sqlite might introduce new issues for packages that already rebuilt against the newest release, which is the main reason I think we should just stay with 3.20 now that it already got to stable... >Can you confirm that you'll be more careful with checking for incompatible changes in future sqlite updates, particularly fts5 changes? Yes, definitely! (In reply to Petr Kubat from comment #6) > >Can you confirm that you'll be more careful with checking for incompatible changes in future sqlite updates, particularly fts5 changes? > > Yes, definitely! OK, great! This update has gone to stable, so with that, I think we're done here. |