Mailing List Archive

Hanno Böck kirjoitti:
> Hi,
>
> I noticed that the sqlite/sqlite3-useflags have no consistent meaning in the
> tree.
>
> E.g.
> - apr-util uses sqlite for sqlite-2.x support and sqlite3 for sqlite-3.x
> support
> - eix uses sqlite for sqlite-3.x support
> Just the first examples I found, you can find countless for both of them in
> the tree.
>
> We should imho decide if
> a) sqlite means sqlite-2.x and sqlite3 means sqlite-3.x.
> b) sqlite means enable sqlite-support always and sqlite+sqlite3 means if both
> are available use sqlite-3.x instead of 2.x.
>
> I don't care which one (or a completely different one), but I think it should
> be made clear. At least I think the current behaviour in the tree doesn't
> really make sense.
>
>

We should remove 2.x from tree and use just sqlite.

Regards,
Petteri

Petteri Räty wrote:
> We should remove 2.x from tree and use just sqlite.

Qt3 supports only sqlite2.

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth

Jan Kundrát kirjoitti:
> Petteri Räty wrote:
>> We should remove 2.x from tree and use just sqlite.
>
> Qt3 supports only sqlite2.
>
> Cheers,
> -jkt
>

Does anything need the sqlite2 support in QT?

Regards,
Petteri

> Does anything need the sqlite2 support in QT?

Not explicitly. Qt can also build against an internal version of sqlite2, so it
shouldn't be too big of a problem to remove this particular dep (but that doesn't
get rid of the flag issue, I suppose).

Caleb

--
gentoo-dev@gentoo.org mailing list

Petteri Räty wrote:
> Does anything need the sqlite2 support in QT?

Anything that uses Qt for database access (and chooses sqlite as the
backend). media-gfx/kphotoalbum is an example.

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth

Petteri Räty wrote:
> We should remove 2.x from tree and use just sqlite.

Oh, and another reason is compatibility -- sqlite2 and sqlite3 use
different on-disk format. sqlite3 can't read sqlite2 data and vice versa.

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth

On Friday 14 September 2007, Hanno Böck wrote:
> I noticed that the sqlite/sqlite3-useflags have no consistent meaning in
> the tree.
>
> E.g.
> - apr-util uses sqlite for sqlite-2.x support and sqlite3 for sqlite-3.x
> support
> - eix uses sqlite for sqlite-3.x support
> Just the first examples I found, you can find countless for both of them in
> the tree.
>
> We should imho decide if
> a) sqlite means sqlite-2.x and sqlite3 means sqlite-3.x.
> b) sqlite means enable sqlite-support always and sqlite+sqlite3 means if
> both are available use sqlite-3.x instead of 2.x.
>
> I don't care which one (or a completely different one), but I think it
> should be made clear. At least I think the current behaviour in the tree
> doesn't really make sense.

how about 'sqlite' means you want sqlite irregardless of version ... then
sqlite-2 either gets punted from apr-util or it gets a local USE
flag 'sqlite-old' for older cruft
-mike

On Fri, 14 Sep 2007 19:18:29 +0200
Hanno Böck <hanno@gentoo.org> wrote:

> Hi,
>
> I noticed that the sqlite/sqlite3-useflags have no consistent meaning
> in the tree.

Python uses USE="sqlite" to install basically pysqlite3..
--
gentoo-dev@gentoo.org mailing list

Caleb Tennis wrote:
>> Does anything need the sqlite2 support in QT?
>>
>
> Not explicitly. Qt can also build against an internal version of sqlite2, so it
> shouldn't be too big of a problem to remove this particular dep (but that doesn't
> get rid of the flag issue, I suppose).
>
> Caleb
>
>
So let's use the internal sqlite2 library and just use the sqlite USE
flag. Since it won't really affect depends that way. It'll basically be
sqlite support...
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:
> On Friday 14 September 2007, Hanno Böck wrote:
>
>> I noticed that the sqlite/sqlite3-useflags have no consistent meaning in
>> the tree.
>>
>> E.g.
>> - apr-util uses sqlite for sqlite-2.x support and sqlite3 for sqlite-3.x
>> support
>> - eix uses sqlite for sqlite-3.x support
>> Just the first examples I found, you can find countless for both of them in
>> the tree.
>>
>> We should imho decide if
>> a) sqlite means sqlite-2.x and sqlite3 means sqlite-3.x.
>> b) sqlite means enable sqlite-support always and sqlite+sqlite3 means if
>> both are available use sqlite-3.x instead of 2.x.
>>
>> I don't care which one (or a completely different one), but I think it
>> should be made clear. At least I think the current behaviour in the tree
>> doesn't really make sense.
>>
>
> how about 'sqlite' means you want sqlite irregardless of version ... then
> sqlite-2 either gets punted from apr-util or it gets a local USE
> flag 'sqlite-old' for older cruft
> -mike
>
I agree with this. I'd take this a step further, using old cruft isn't a
choice anymore. If an app supports sqlite2 and sqlite3, we'll have a
USE=sqlite that'll enable sqlite3... sqlite2 just isn't an option
anymore. The conversion process is very simple...

Step 1) mv mydatabase.db mydatabase.db-old
Step 2) sqlite mydatabase.db-old .dump | sqlite3 mydatabase.db
Step 3) Profit!

I'm willing to start making this change asap in the tree. Since sqlite2
and sqlite3 are SLOTED, people won't lose their sqlite2 binary and will
be able to make the conversion. I'll even add an ewarn for people to
make sure to update their databases to sqlite3.

Also, qt already uses it's own internal sqlite2 library and doesn't use
the system library so that won't be a problem.
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:
> how about 'sqlite' means you want sqlite irregardless of version ... then
> sqlite-2 either gets punted from apr-util or it gets a local USE
> flag 'sqlite-old' for older cruft
>
Wouldn't be better to determine what version of sqlite should be used
based on the version of sqlite currently installed on the system?
Something like:
sqlite_atom=$(best_version dev-db/sqlite)
sqlite_major_version=${sqlite_atom#*/*-} #reduce it to $PV-$PR
sqlite_major_version=${sqlite_major_version%%.*} # major version

... ebuild stuff...
econf \
$(use_enable sqlite sqlite${sqlite_major_version})

Better yet, why not make an sqlite.eclass that would contain at least
get_sqlite_major_version()?

Alin Năstac kirjoitti:
> Mike Frysinger wrote:
>> how about 'sqlite' means you want sqlite irregardless of version ... then
>> sqlite-2 either gets punted from apr-util or it gets a local USE
>> flag 'sqlite-old' for older cruft
>>
> Wouldn't be better to determine what version of sqlite should be used
> based on the version of sqlite currently installed on the system?
> Something like:
> sqlite_atom=$(best_version dev-db/sqlite)
> sqlite_major_version=${sqlite_atom#*/*-} #reduce it to $PV-$PR
> sqlite_major_version=${sqlite_major_version%%.*} # major version
>
> ... ebuild stuff...
> econf \
> $(use_enable sqlite sqlite${sqlite_major_version})
>
> Better yet, why not make an sqlite.eclass that would contain at least
> get_sqlite_major_version()?
>

No. The produced binaries can't depend on the build system like this.
Breaks binary packages etc.

Regards,
Petteri