From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: [PATCH] Add and use sqlite-legacy-for-python Date: Fri, 12 Feb 2016 17:09:58 -0800 Message-ID: <87egch8lg9.fsf@dustycloud.org> References: <20160208164641.GA28440@thebird.nl> <87ziv9poua.fsf@gnu.org> <87h9hd8o2k.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUOip-0001TT-HI for guix-devel@gnu.org; Fri, 12 Feb 2016 20:10:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUOio-0001Hb-Gi for guix-devel@gnu.org; Fri, 12 Feb 2016 20:10:03 -0500 In-reply-to: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: "Thompson, David" Cc: guix-devel Thompson, David writes: > On Fri, Feb 12, 2016 at 7:13 PM, Christopher Allan Webber > wrote: >> Ludovic Court=C3=A8s writes: >> >>> Pjotr Prins 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=E2=80= =99re >>> unlikely to end up mixing two different SQLite versions. >>> >>> Ludo=E2=80=99. >> >> 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... :)