guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add and use sqlite-legacy-for-python


From: Christopher Allan Webber
Subject: Re: [PATCH] Add and use sqlite-legacy-for-python
Date: Fri, 12 Feb 2016 17:09:58 -0800
User-agent: mu4e 0.9.13; emacs 24.5.1

Thompson, David writes:

> On Fri, Feb 12, 2016 at 7:13 PM, Christopher Allan Webber
> <address@hidden> wrote:
>> Ludovic Courtès writes:
>>
>>> Pjotr Prins <address@hidden> 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

I share your concern, and admittedly don't understand myself what the
implications are here (despite producing a patch, egads!).  It's part of
the standard library though.  I would *think* that it would stay
pointing at the very specific version of sqlite.  Nonetheless, it does
seem unsettling, and unclear to me personally if something unexpected
could happen.

Maybe some "expert" could weigh in... :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]