Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

restore compatibility with sqlite3 v3.8 #15819

Merged
merged 1 commit into from Mar 27, 2019

Conversation

Projects
None yet
5 participants
@olafhering
Copy link
Contributor

commented Mar 27, 2019

Wrap defines from new sqlite3 versions:
SQLITE_IOERR_VNODE was introduced in v3.9.1
SQLITE_IOERR_AUTH was introduced in v3.10.0

Fixes commit 2e54c80

Signed-off-by: Olaf Hering olaf@aepfle.de

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • Clean up (non-breaking change which removes non-working, unmaintained functionality)
  • Improvement (non-breaking change which improves existing functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that will cause existing functionality to change)
  • Cosmetic change (non-breaking change that doesn't touch code)
  • None of the above (please explain below)

Checklist:

  • My code follows the Code Guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the Contributing document
  • I have added tests to cover my change
  • All new and existing tests passed
restore compatibility with sqlite3 v3.8
Wrap defines from new sqlite3 versions:
SQLITE_IOERR_VNODE was introduced in v3.9.1
SQLITE_IOERR_AUTH was introduced in v3.10.0

Fixes commit 2e54c80

Signed-off-by: Olaf Hering <olaf@aepfle.de>
@olafhering

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

As an alternative, adjust cmake/modules/FindSqlite3.cmake, add sqlite3>=3.10.0.

@Rechi

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

sqlite3 3.10.0 was released 6th January 2016, that's more then 3 years ago.
I do not see a need to support something even older.

@olafhering

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

Well, if "was released N years ago" was ever a valid argument, one could jump straight to newer toolchains or whatever else seems appropriate. Is think there are users out there who do not want, and even need, to upgrade parts of their system.

Was there any substantial work in xbmc/dbwrappers/sqlitedataset.cpp that warrants an updated pkgconfig check? To me it does not look like that, but I do know nothing about sqlite3.

@fritsch

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html <- I'd highly suggest you to upgrade immedietaly - especially for 3.8

@olafhering

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

Not an argument either, CVEs are fixed by zypper patch.

@notspiff

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

it's 2 lines, additions to an enum already riddled with tons of ifdefs, and helps a whole distro. i really don't think this is worth holding back.

@fritsch

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

Not an argument either, CVEs are fixed by zypper patch.

Don't think only inside your distro silo box.

But I agree with @notspiff

@pkerling

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

We usually keep support if it helps a distro and is not too much work, and in this case I think the latter part is quite clear. To be honest, I mainly look at Debian stable and Ubuntu LTS when making such decisions. Can you tell us for what specific distro/release this is for future reference?

Well, if "was released N years ago" was ever a valid argument, one could jump straight to newer toolchains or whatever else seems appropriate. Is think there are users out there who do not want, and even need, to upgrade parts of their system.

Of course there are, but the quesiton is whether we want to/can support that. There are always "users out there" doing XY or wanting to do Z, especially with Kodi :-) You also have to consider that Kodi is a very end-user-centric application that does not typically run on server distros and the like (and is not really intended to anyway). We need to have at least up-to-date kernel and mesa for a good multimedia experience.

@pkerling pkerling added this to the Leia 18.2-rc1 milestone Mar 27, 2019

@olafhering

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

This is for Leap 42.3.

Regarding the security argument: if one would go that route, only the "very latest" would be allowed which means consumers of Kodi must compile their own copy, despite the fact that zypper patch just fixed it without bumping the library version.

@pkerling

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

Regarding the security argument: if one would go that route, only the "very latest" would be allowed

You're taking this far too extreme

@pkerling pkerling merged commit a19fb7e into xbmc:master Mar 27, 2019

1 check passed

default You're awesome. Have a cookie
Details

@olafhering olafhering deleted the olafhering:sqlite3 branch Mar 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.