sqlite3: bug with monotone

[Warren Young]

On 5/30/2013 16:36, Yaakov (Cygwin/X) wrote:
> DON'T BREAK Cygwin programs for the sake of those NOT USING Cygwin.

Where did you get the idea that my stance favors those not using Cygwin?

My choice favors those who want to use Cygwin *and* native Windows 
programs, together.  That's approximately 100% of all Cygwin users.

Did you miss the part in the referenced Stack Overflow post where I 
talked about how we had already tried building SQLite your way?  The 
post was a sort of damage control resulting from that experiment.

SQLite is one of the most widely used libraries, with hundreds of 
millions[1] of deployments.  This problem isn't just about Cygwin svn 
vs. TortoiseSVN.  It's also about Firefox, and Chrome, and Flash, and 
Skype, and Lightroom, and Dropbox, and...[2]

With so many native Windows programs using SQLite, it's virtually 
certain there are more bad interactions waiting to bite us if we make 
Cygwin SQLite incompatible with native SQLite again.

I see you're using Thunderbird.  Are you willing to give up the ability 
to use sqlite(1) on a live Thunderbird DB file?

> Please fix sqlite3 accordingly.

I don't see that switching Cygwin SQLite back to Unix mode is an option 
as long as it has a real potential of breaking half a billion other 
programs.

As I see it, the practical options are:

1. We continue waiting for someone to to implement a per-process or 
per-subtree mandatory locking feature in Cygwin, so that "Unix mode" 
SQLite on Cygwin can be configured to cooperate with native SQLite.

2. You figure out which of the thousands of lines of code separating 
Unix mode from Cygwin mode in SQLite breaks monotone.  With any luck, 
it's not in the file locking code, so we can talk about selectively 
patching that piece of Unix mode in over the top of the stock Cygwin 
code.  The current package includes one such patch already.  (That patch 
makes it use the Unix mode /tmp path selector to get around a 
permissions issue.)

3. I start shipping two different versions of the libsqlite3 package, 
each built differently, and deploy the Unix mode version as 'test', 
perpetually.  (There isn't any more elegant way to ship two different 
versions of the same library, each of which could satisfy setup.exe's 
dependency checker, is there?)  Then individual users can choose which 
side of the fence they want the breakage to land on.

If you don't like those options, then I offer, in all seriousness:

4. You take over maintainership of the official Cygwin SQLite packages. 
  Then you can build it however you like.


[1] https://www.sqlite.org/mostdeployed.html
[2] https://www.sqlite.org/famous.html


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple