* Joel Rosdahl <[EMAIL PROTECTED]> [2005-04-13 22:42+0200] > Hugo Haas <[EMAIL PROTECTED]> writes: > > > Would it be possible to have version 1.1.6 packaged in order to > > access SQLite 3.x databases? > > Well, yes, but I would like to provide a clean upgrade path from older > SQLite 2.x-based python-sqlite packages. > > I see the following solutions: > > 1. Just release a new python-sqlite package with PySQLite 1.1.x. > 2. Keep python-sqlite as a PySQLite 2.x package and create a new > package, say python-sqlite3, with PySQLite 1.1.x and let it > conflict with python-sqlite. (It must conflict, since it uses the > same API.) > 3. Ignore PySQLite 1.1.x and wait for PySQLite 2.x. (PySQLite 2.x uses > a different API than PySQLite 1.x and can therefore coexist with > PySQLite 1.0.x.) > > The problem with solution 1 is that all existing applications will > break unless the user does something like > > mv foo.db foo.db.old > sqlite foo.db.old .dump | sqlite3 foo.db > > for each database. That feels unacceptable to me, since the user can't > possibly be expected to know what should be done in all cases. > > Solution 2 is maybe feasible, but it's kind of boring. > > So far, my intention has been to go for solution 3. Opinions on this? > (Are there other solutions?) > > You might also want consider using python-apsw, which now is part of > unstable.
This is what I have done in the meantime. I agree about solution 1. I am not familiar with the release cycles of the PySQLite people, so I trust your judgment that 3 is better than 2. Cheers, Hugo -- Hugo Haas - http://larve.net/people/hugo/
signature.asc
Description: Digital signature
