On Fri, Feb 12, 2016 at 7:13 PM, Christopher Allan Webber <cweb...@dustycloud.org> wrote: > Ludovic Courtès writes: > >> Pjotr Prins <pjotr.publi...@thebird.nl> skribis: >> >>> Patch b24765139c8940541b23f84592d3580d53f71d71 >>> >>> (define-public sqlite >>> (package >>> (name "sqlite") >>> - (version "3.8.11.1") >>> + (version "3.10.0") >>> (source (origin >>> >>> is the cause of python(2|3)-sqlalchemy breaking. I confirmed that by >>> regressing to the original sqlite package. Since the python binding is >>> part of the interpreter, I suspect there may be more python modules >>> vulnerable. I updated python-sqlalchemy to latest and that makes no >>> difference. Its tests fail on sqlite 3.10.0 and pass on 3.8.11.1. >>> >>> What do we do? Revert on this sqlite patch for the new guix release? >>> Or add a second sqlite package and have that as a python dependency? >> >> I would do the latter, assuming that soon a new python-sqlalchemy >> release would solve the problem. WDYT? >> >> This is probably OK since python-sqlalchemy is a leaf, and so we’re >> unlikely to end up mixing two different SQLite versions. >> >> Ludo’. > > Will sqlalchemy really remain a leaf node? I hope not, since I'm > working on packaging MediaGoblin now :)
Yeah, sqlalchemy being a leaf node is accidental. It's a library that will be depended on by MediaGoblin and maybe other software. > Regardless, I agree that the second approach seems to be the right one. > I've built a modified package, sqlite-legacy-for-python, and put it to > use. I built it and confirmed it builds fine and that the tests pass, > and with it, the tests pass in python-sqlalchemy too. I'm concerned about this. What exactly is being used here, a client library? If so, it means that we may have an issue when a python application uses a library that wants to dynamically link against both the normal sqlite library and this older version. Maybe this is still fine, but proceed with caution. - Dave