This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sqlite3: bug with monotone


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]