pysqlite 1.0 is for sqlite 2.x pysqlite 1.1 is for sqlite 3.x so we need a slot for it. Reproducible: Always Steps to Reproduce:
Quick note here to the python herd: sqlite3 and sqlite2 databases are completely incompatible, yet they've kept the module name 'pysqlite' for both versions. I think we should hold off adding pysqlite-1.1 and see if they change the module name to pysqlite2 when the final release comes out so we can slot them and not have to change every existing app using pysqlite1 to avoid incompatible databases in existing apps.
pysqlite3-x.y.z would make much more sense. If you name it pysqlite2, then everybody would think it's for sqlite2, instead of sqlite3. Nonetheless, sqlite2 should be faded out ASAP by all projects IMHO. But this lays not in our hands.
The author originally wanted to leave the module named "pysqlite" for all versions and force people to convert their databases, but it looks they changed their minds and newer versions will be named appropriately, which is good news for us: http://sourceforge.net/mailarchive/forum.php?thread_id=6021987&forum_id=9559 So, slotting will be good, but not till the next version comes out with the new name change.
Stefan: sqlite3 has had a _lot_ of data corruption bugs so I don't think people should abandon sqlite2 just yet. Anyway on to the subject. I think pysqlite 1.1 should be added to portage for people who wants/have to work with sqlite3. pysqlite2 is still alpha.
It's good think to create a new slot for pysqlite1.1. e.g. I had to write ebuild for it and thought that developer forgot about his work. Have both versions and compare them is necessary.
Can pysqlite-1.1 be bumped please? sqlite-3.2.1 is marked stable, but there is no stable python bindings for it. pysqlite-2* can't be marked stable, as it has a new API and is still considered as alpha. That's what we need pysqlite-1.1 for the moment, to make the switch to sqlite-3 possible. As an exemple, pysqlite-2* is incompatible with Trac (see http://projects.edgewall.com/trac/wiki/TracInstall), so Trac users are required to use sqlite-2.8 and can't switch their databases to sqlite-3. Maybe pysqlite-2* ebuilds should even be hard masked?
Actually, I'm interested in seeing pysqlite-2.x stable before starting trac-0.9 ebuilds releases (which will support sqlite-3/pysqlite-2). Apparently pysqlite-1.1 has some API problems.
so what is the status of this? i know that we have slotted versions of pysqlite-2.x.x to correspond to sqlite-3.2.x. i suppose we need to go through all the packages taht depends on pysqlite and make sure they either have the deps set as <dev-python/pysqlite-2 or >=dev-python/pysqlite-2
Current slots are OK for me. It would be great if pysqlite-2 would be marked as stable some day. Correcting ebuilds of packages that depend on pysqlite would be nice. Actually, the dependency should be either <dev-python/pysqlite-1.1 or >=dev-python/pysqlite-2. The following ebuilds should be corrected: dev-python/sqlobject (have <dev-python/pysqlite-2.0) media-sound/bossogg (have dev-python/pysqlite) net-irc/supybot (some have >=dev-python/pysqlite-0.4.3
Christian, net-print/pykota is the last remaining package that needs to have the pysqlite dependency specified for either pysqlite-2 or <pysqlite-2. Can you please check that?
I'm afraid I'll have to pass the pykota test to Patrick: I lack my dev box at now :-(
Ok, updated pykota to dep on =dev-python/pysqlite-2*
thanks for the quick response. i believe this solves the pysqlite slotting issues now. closing this bug.
