Re: Promote sqlite 3.7.13-1 from test status?

[Warren Young <warren@etr-usa.com>]

On 8/16/2012 10:34 AM, Brian Wilson wrote:
>
> Corina

Corinna.

> is correct, Cygwin is supposed to be a Posix compliant environment

It's also supposed to interoperate with native Windows programs.

> If you want to use Windoze tools, why are you using Cygwin?

First, instant 100 point credibility penalty for being puerile.

Second, the whole reason for using Cygwin is so you could have a 
Linux/POSIX environment *on Windows.*  If you have no need for Windows 
programs and want a Cygwin-like environment, wouldn't you be running 
Linux, or a BSD, or OS X, or Solaris, or...?

Okay, so you come back saying something about how there should be some 
Chinese Wall between the Cygwin and native Windows lands.  In that case, 
I recommend you install one of the above-named OSes in a VM.  It'll be 
faster and more featureful.

I'm actually struggling to come up with a reason why you would *ever* 
run Cygwin if you didn't ever want it to touch the native Windows side 
of things, or vice versa.  I guess it uses less RAM and starts up faster 
than a VM....

> you really must, why not set up Apache under Cygwin and access the Cygwin
> Subversion repository through the defined http server interface and the
> issue of file locking becomes moot.

1. That wouldn't provide all the features some people want.  TortoiseSVN 
provides a really nice version tree and a spiffy graphical diff 
facility, for example.

2. As David said, we're not talking about locks in the repository itself 
here.  We're talking about a lock on the .svn/wc.db file at the top of 
the client-side checkout tree, introduced in svn 1.7.

> As a worst case scenario, why can't the direct SVN access locking behavior
> be determined by setting an environment variable.

Because there's no easy way to do that.

You can't compile SQLite for *both* for Windows and Unix at the same 
time.  The code simply isn't structured to let you swap I/O subsystems 
in and out like that.

I could instead disentangle Windows, Cygwin and Unix in the SQLite code, 
and make the Cygwin code switch-hit between locking methods.  But keep 
in mind, the only reason I maintain the SQLite package is that I know 
what it is and how to test it, so I rescued it from being removed from 
the Cygwin distro back when its previous maintainer abandoned it.  I 
simply don't care enough about it to bother with such a big rewrite.  It 
doesn't help that upstream has ignored multiple requests to integrate 
trivial patches for it.  I expect they'd be certain to ignore a big one 
like this, so I'd then have to keep tracking upstream changes to 
reintegrate it each time.

Bottom line, the only options open to you while I'm maintainer are 
trivial patches and build system changes.

I suppose I could release *two* versions of SQLite, one for each build 
method.  I'd still nominate the Windows-aware version as the default.

I'm not sure setup.exe's dependency resolution code can cope with this, 
however.  I don't recall hearing anything about features like RPM's 
"Provides", which lets two different package provide a given facility, 
interchangeably.  If not, then the nonstandard package would have to be 
made available for manual download only, to be unpacked by hand and kept 
up to date by hand each time setup.exe overwrites it with a new version. 
  Blech.

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