Bug#326648: libsqlite3-0: database handles can't be shared among threads any more

[Adeodato Simó <asp16@alu.ua.es>]

Package: libsqlite3-0
Version: 3.2.5-1

  [debian-devel CCed because I'm asking for advice at the end.]

  Until sqlite 3.2.2, a database handle could be opened in one thread
  and used in another. In 3.2.5 this has been disabled, and upstream
  recommends to open a db handle for each handle; which has generated a
  bit of traffic in the mailing list:

    http://thread.gmane.org/gmane.comp.db.sqlite.general/13957
    http://thread.gmane.org/gmane.comp.db.sqlite.general/14007

  The reason for this change is that it didn't properly work on some
  Linux systems. See these messages from the sqlite author:

    http://article.gmane.org/gmane.comp.db.sqlite.general/13961
    http://article.gmane.org/gmane.comp.db.sqlite.general/14015

  My amarok package uses this feature (sharing db handles accross
  threads), and with the recent upload of sqlite3, its sqlite-based
  collection support no longer works (#326562, #312386). What is worse,
  when talking with upstream about it, they tell me that hey have no
  plans on changing their source code -- as they ship an internal copy
  of sqlite, they'll re-enable the feature there instead.

  If sqlite upstream fails to provide a solution for this, I fear I will
  have to use the internal copy of sqlite that amarok provides (*).
  Unless the solution is provided by the Debian package instead; but
  this would be diverging from upstream, and I don't think it's a really
  good idea unless we can know for sure we don't belong to the "does
  sometimes not work" category outlined by D. Richard Hipp. Anybody has
  an opinion on this?

    (*) I'd be very unhappy with this, but I can't go on with "install
        libsqlite3-0 3.2.2-3 and put it on hold" forever.

  Also, I have no idea what's the case for Debian: "On some versions of
  Linux, a thread is not able to override locks created by a different
  thread in the same process." Does this depend on the kernel, on libc,
  or on something else?

  Thanks,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Faced with the choice between changing one's mind and proving that there
is no need to do so, almost everyone gets busy with the proof.
                -- J.K. Galbraith