Re: problem with git-cvsserver

aonghus [off-list ref] writes:

I don't know much about the perl SQLite package, but it seems that
git-cvsserver is not loading the correct module. The line 'use DBI;'
seems to load only this module:

   'DBI.pm' => '1.51 from /usr/lib/perl5/DBI.pm'

Does it need something else to load the SQLite module?

When things are properly installed, it should be enough to say
'use DBI' upfront and then 'DBI->connect("dbi:Foo:...")' should
be enough to use DBD::Foo backend of the DBI interface.

I am on Debian etch plus some from testing and have these:

        perl (5.8.8-6.1)
        perl-base (5.8.8-6.1)
        libdbi-perl (1.51-2)
        libsqlite3-0 (3.3.7-1)
        libdbd-sqlite3-perl (1.12-1)

Does this work for you?

-- >8 -- cut here -- >8 --
#!/usr/bin/perl -w
use DBI;
my $dsn = 'dbi:SQLite:dbname=foo';
my $dbh = DBI->connect($dsn, '', '');
-- 8< -- cut here -- 8< --

If not, does it work for you if you substitute $dsn with
'dbi:mysql:dbname=test'?  The error message you showed us in
your earlier message said mysql was one of the backend your DBI
knows about while SQLite is not.

This did not work for me before installing libdbd-sqlite3-perl
and gave a very similar error message as you had.

What's puzzling is that you said you have these:

   $ dpkg -S SQLite
   libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz
   libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so

but that is exactly what I am seeing _after_ installing
libdbd-sqlite3-perl.

On 8/31/06, Junio C Hamano [off-list ref] wrote:

I am on Debian etch plus some from testing and have these:

        perl (5.8.8-6.1)
        perl-base (5.8.8-6.1)
        libdbi-perl (1.51-2)
        libsqlite3-0 (3.3.7-1)
        libdbd-sqlite3-perl (1.12-1)

Does this work for you?

-- >8 -- cut here -- >8 --
#!/usr/bin/perl -w
use DBI;
my $dsn = 'dbi:SQLite:dbname=foo';
my $dbh = DBI->connect($dsn, '', '');
-- 8< -- cut here -- 8< --

Hi! all this seems to have happened during NZ's night, so I'm only
catching up. +1 on all the diagnosis Junio is proposing. Can't think
of anything more relevant to add. The code was developed mainly on a
bunch of debian sarge/etch boxes using all the standard
libdbd-sqlite-perl libs, and a gentoo box.

Actually, just looking at my etch dev box, libdbd-sqlite-perl is
0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is
significant. Perhaps SQLite v3 has a different invocation / driver
name?

BTW, I just doublechecked, cvsserver isn't mangling the lib path in
any way. However, the environment it's running under may have a
strange PERL5LIB.

cheers,


martin

On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:

[git-cvsserver and trouble with Perl DBI and SQLite]

Actually, just looking at my etch dev box, libdbd-sqlite-perl is
0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is
significant. Perhaps SQLite v3 has a different invocation / driver
name?

Yes, SQLite v2 and SQLite v3 are different and binary incompatible.

However, on Debian 'etch' you can install packages for both versions
concurrently; most packages for SQLite have either a '2' or a '3' in the
name. Packages without the number use the "best current choice" which is
"3" in 'etch' at the moment but was "2" not too long ago.

So at this moment in Debian 'etch' SQLite3 is the default version and
calling

        my $dsn = 'dbi:SQLite:dbname=foo';

will use the SQLite3 driver internally, for which you must have
installed the "libdbd-sqlite3-perl" package. Just for the record, if
you'd wanted the older SQLite2 version you would install the
"libdbd-sqlite2-perl" package and from Perl call "my $dsn =
'dbi:SQLite2:dbname=foo';".

I'd guess that you were unfortunate enough to just install some packages
during the transition and now some parts look for the "2" version
and other parts for the "3" version. Probably just installing the
"libdbd-sqlite3-perl" package and upgrading the other sqlite packages
(from synaptic say to easily find them!) will probably cure your situation.

Incidentally I'd guess that in itself SQLite2 (so version 2) would also
function perfectly well for git-cvsserver (as would PostgreSQL or
MySQL), it's probably in this case just a slight version skew between
packages!
-- 
Marco Roeland

Marco Roeland wrote:

On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:

  

quoted

[git-cvsserver and trouble with Perl DBI and SQLite]

Actually, just looking at my etch dev box, libdbd-sqlite-perl is
0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is
significant. Perhaps SQLite v3 has a different invocation / driver
name?
    

Yes, SQLite v2 and SQLite v3 are different and binary incompatible.

However, on Debian 'etch' you can install packages for both versions
concurrently; most packages for SQLite have either a '2' or a '3' in the
name. Packages without the number use the "best current choice" which is
"3" in 'etch' at the moment but was "2" not too long ago.

So at this moment in Debian 'etch' SQLite3 is the default version and
calling

        my $dsn = 'dbi:SQLite:dbname=foo';

will use the SQLite3 driver internally, for which you must have
installed the "libdbd-sqlite3-perl" package. Just for the record, if
you'd wanted the older SQLite2 version you would install the
"libdbd-sqlite2-perl" package and from Perl call "my $dsn =
'dbi:SQLite2:dbname=foo';".

I'd guess that you were unfortunate enough to just install some packages
during the transition and now some parts look for the "2" version
and other parts for the "3" version. Probably just installing the
"libdbd-sqlite3-perl" package and upgrading the other sqlite packages
(from synaptic say to easily find them!) will probably cure your situation.

Incidentally I'd guess that in itself SQLite2 (so version 2) would also
function perfectly well for git-cvsserver (as would PostgreSQL or
MySQL), it's probably in this case just a slight version skew between
packages!
  

Hi,

Thanks for all the help- I have it working now. It was not a fault with 
git-cvsserver at all- more like my own stupidity. The problem was that I 
had checked the versions on my client machine and forgotten to update 
the cvs/git server! Once I updated it and installed the 
libdbd-sqlite3-perl package (on the server) everything works as expected.
 
So, just to confirm, git-cvsserver is working on a debian 
testing/unstable machine (acting cvs/git server) with the following 
versions:

    libdbd-sqlite3-perl (1.12-1)
    libdbi-perl (1.51-2)
    libsqlite3-0 (3.3.7-1)
    perl (5.8.8-6.1)
    perl-base (5.8.8-6.1)


Apologies for wasting your time, looks like my caffeine levels are 
getting dangerously low...

a

 

On 8/31/06, Marco Roeland [off-list ref] wrote:

Yes, SQLite v2 and SQLite v3 are different and binary incompatible.

However, on Debian 'etch' you can install packages for both versions
concurrently; most packages for SQLite have either a '2' or a '3' in the
name. Packages without the number use the "best current choice" which is
"3" in 'etch' at the moment but was "2" not too long ago.

Thanks for the info!

I have to say though: Ouch. Do you know if there's an upgrade path for
apps? Does v3 detect you've got a v2 file and do something smart
(upgrade in place / spit out a readable error)?

...

I'd guess that you were unfortunate enough to just install some packages
during the transition

Problem is that we have to help with the transition for users that
started with v2 and get upgraded to v3 at the app level I suspect.

Incidentally I'd guess that in itself SQLite2 (so version 2) would also
function perfectly well for git-cvsserver (as would PostgreSQL or
MySQL)

This was developed against v2. If v3 is backwards compatible, it'll
just work. If not... we'll hear about it soon ;-) Pg/MySQL aren't
really supported, though it wouldn't be that hard.



martin

Hi,

On Fri, 1 Sep 2006, Martin Langhoff wrote:

Pg/MySQL aren't really supported, though it wouldn't be that hard.

AFAIK Pg/MySQL/all-the-others want to have a common place where to put the 
database files. This is a huge disadvantage over SQLite, where you can put 
it anywhere you want (e.g. /blabla/.git/...). This also makes installation 
way easier.

Ciao,
Dscho

On 9/1/06, Martin Langhoff [off-list ref] wrote:

I have to say though: Ouch. Do you know if there's an upgrade path for
apps? Does v3 detect you've got a v2 file and do something smart
(upgrade in place / spit out a readable error)?

Oh, grumble. See the comment at the bottom of
http://www.sqlite.org/formatchng.html

We may need to add something in the doco pointing to this "technique",
and perhaps the URL as later versions may do something different.

I do wonder what the debian packaging does, perhaps the v3 package
forces an upgrade to the v2 package that renames the cli binary? I
guess the drawback of having the DBs anywhere in the FS is that the
packaging can't upgrade them for you as it does with Pg for instance
:(



m

On Friday September 1st 2006 at 12:07 Martin Langhoff wrote:

[warning: discussion about sqlite; no direct git serviceable parts inside!]

quoted

I have to say though: Ouch. Do you know if there's an upgrade path for
apps? Does v3 detect you've got a v2 file and do something smart
(upgrade in place / spit out a readable error)?

Applications for both v2 and v3 can work on the same machine at the same
time. Both versions will not corrupt a database of the other version
and will immediately stop with an error, although the error isn't very
readable (doesn't mention _which_ version it saw or needed).

They do not perform an upgrade in place.

But as sqlite or sqlite3 databases are standalone files, most of the
time just use the sqlite version that is standard for your platform
and/or version. For new development v3 is the way to go, as v2 is in
deep sleep maintenance now.

Not just the database format changed in v3, the whole API changed
incompatibly.

Oh, grumble. See the comment at the bottom of
http://www.sqlite.org/formatchng.html

We may need to add something in the doco pointing to this "technique",
and perhaps the URL as later versions may do something different.

I do wonder what the debian packaging does, perhaps the v3 package
forces an upgrade to the v2 package that renames the cli binary? I
guess the drawback of having the DBs anywhere in the FS is that the
packaging can't upgrade them for you as it does with Pg for instance
:(

The commandline programs are called 'sqlite' and 'sqlite3' so there is
no "upgrade", you can have the two different versions simultaneously
installed and working on the same machine.

Unfortunately the 'sqlite3' doesn't directly read the 'sqlite' format
and neither the other way round. You can convert a database easily from
the one format to the other:

$ echo .dump | sqlite database.v2.dat > dump.v2.dat
$ sqlite3 < dump.v2.dat database.v3.dat

If you don't use the new features in sqlite3 you can even convert back
in the same way:

$ echo .dump | sqlite3 database.v3.dat > dump.v3.dat
$ sqlite < dump.v3.dat database.v2.dat

Use a non-existent file for the target database, and sqlite(3) will
create the database for you. Do check the conversion as error reporting
in the commandline tools in this "batch" mode is sometimes rather sparse
or non-existent!

Once you got it finally going I find that sqlite(3) is a fast, reliable
and quite handy database. Especially, as Johannes said, its standalone
nature makes developing and deploying very easy.
-- 
Marco Roeland