Re: Promote sqlite 3.7.13-1 from test status?

[Warren Young <warren at etr-usa dot com>]

On 8/16/2012 6:26 AM, Corinna Vinschen wrote:
> On Aug 16 06:01, Warren Young wrote:
> > This recent wish for SQLite on Cygwin to act more Unix-like is the
> > first such request I've received, and I don't remember it being an
> > issue with the previous maintainer, either.
>
> Maybe the reason is because subversion didn't use SQLite before?

That's mere happenstance.  There's nothing special about Subversion in 
this regard.  It could have happened with any other pair of SQLite based 
programs.  The fact that it hasn't until now means the DITCW principle 
isn't buying us much in this case.

Understand Corinna, I see your point, and Achim's.  Remember that I 
accepted Achim's patch and released 3.7.12.1-1 including it.  Making 
Cygwin SQLite behave in a POSIXy way feels right.  But, given that the 
new locking behavior causes actual people actual problems, purity alone 
isn't looking like such a good reason to keep the new behavior.

If we discard purity as a reason to do this, all we're left with is the 
actual problem brought up by one person (Achim) in N years.  We can't 
solve that problem without causing problems for many others.

> This behaviour breaks concurrency with other Cygwin executables
> using POSIX calls for file locking.

I agree, in principle, the 3.7.3/13-1 locking behavior is Wrong (tm).

In practice, it breaks *one person's* program, while allowing many 
others' programs to work correctly.

It's not like I've refused to even try the pure path.  I did try it. 
Now that the experiment's been run and I want to revert that change, 
returning to the way it's been for *years*, you want me to keep the 
problematic change, and thus keep the problems.  Why would I?

If you're feeling adamant about this issue, you should take this 
package's maintainership away from me, and give it to someone who will 
do it the way you want.

Seriously.  No bluff, no rancor.  I already tried to persuade Achim to 
take over maintanership, since it seemed he cared a lot more about the 
Cygwin SQLite package than me.  He chose not to accept, but maybe he's 
still persuadable.

> > Advisory locking only works when all players cooperate.  We can't
> > assume that on Windows, unless we set up an insular Cygwin ghetto.
>
> So, are you saying that Cygwin should use mandatory file locking?

In a situation like this, you have three choices:

1. Use mandatory locking in the Cygwin program.  Ugly, but useful work 
gets done.

2. Tell all users of the Cygwin program to stop using the native Windows 
program or switch to a Cygwin alternative.  This is a bad choice as a 
rule, since it tells the world Cygwin doesn't play well with others. 
It's worse in this case due to N years of the Cygwin program playing 
well with the Windows program.  Additionally, there is no GUI Subversion 
client in the Cygwin package repo.

3. Tell all users of the native Windows program to stop using the Cygwin 
program.  Again, it says Cygwin doesn't play well with others.

I suppose there's a fourth choice, where everyone refuses to budge and 
you get Palestine.  But, that's not going to happen here, because I've 
already told you you can take the West Bank if you want it.

> Stop right here.  If the compatibility with native WIndows tools is more
> important than the compatibility with POSIX and CYgwin POSIX tools with
> each other, then why do we bother at all to implement POSIX calls in the
> most POSIXy or Linuxy way possible?

In principle, yes, you're right.  But that's the problem with rigid 
principles: there are always specific breakdown cases where the 
principle causes more harm than good.  This is one of those cases.

--
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