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

Re: Review/sponsor needed: sqlite2

On Sat, 23 Apr 2005 17:28:33 -0400, Ignacio Vazquez-Abrams wrote:

> On Sat, 2005-04-23 at 21:20 +0200, Michael Schwendt wrote:
> > A few additional comments on SQLite v2 versus v3:
> > 
> >  * SQLite v3 file format is incompatible with v2.
> >    Databases need to be converted with sqlite utility.
> Good to know. Does it warrant adding a note in either of the packages?

It's something which needs to be addressed for any package, which created
sqlite v2 databases in the past and is built against sqlite v3 later. It
could be feasible to dump and rebuild databases on-the-fly in package
upgrade scriptlets. I think that's something the package maintainers need
to consider.

> > And with regard to any plans on upgrading the FC-3 branch, comments
> > on sqlite v2 dependencies:
> > 
> >  * Package "kannel": not built for FC3
> >  
> >  * Package "moodss": current FC3 binaries not built with sqlite-tcl
> These should be modified to use sqlite2 I'm thinking.

For "kannel" it's trivial, since the sqlite2 package only renames
the package and doesn't introduce any important changes. But I leave
the decision of what to do with kannel to its package owner: Matthias

> >  * Package "php-pecl-sqlite": built with internal sqlite 2.8.14
> A good reason to have some sort of 2.8.x version around externally.

Yes, it ought to be built with the external sqlite.
> >  * Package "python-sqlite" in FC-3 branch: no deps which use it
> And here's where I'm stumped. It's certainly possible to create a
> python-sqlite2 package, but parallel install will be broken. Or it could
> be patched to have a different module name, but that breaks Python
> programs that use it.
> Of course, once sqlite2 comes in this package won't be an upgrade
> blocker for anything in Core or Extras 4, so I'm wondering if anything
> should be done at all about it.

I haven't had a look at the python-sqlite API. Has it changed? Isn't it
an upwards compatible API which separates Python programmers from the
SQLite API?  As I suggested before, we should let the FC-3 branch rest
in peace unless we need more sqlite usage in there. For FE4 we don't
need a python-sqlite2. Python packages should be able to use python-sqlite
from FC4.

> Shall I go ahead and import sqlite2 then?
Fine with me in "devel" tree, but I don't maintain the three packages
mentioned above. So, to demonstrate that coordination among packagers
works, how about the package owners give their explicit "okay" at this

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