Avoid collisions between parallel installations of Cygwin

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Tue Oct 13 21:33:00 GMT 2009

On Tue, Oct 13, 2009 at 12:38:34PM -0500, Brian Ford wrote:
>On Tue, 13 Oct 2009, Christopher Faylor wrote:
>> On Tue, Oct 13, 2009 at 10:22:05AM -0500, Brian Ford wrote:
>> >On Tue, 13 Oct 2009, Christopher Faylor wrote:
>> >
>> >> The policy of "always use the newest" still makes sense to me.
>> >
>> >Disclaimer: We are not the Red Hat customer who payed for this feature.
>> >
>> >This policy only makes sense in an ideal world where complete backward
>> >compatibility is guaranteed by the development team, and where any new bugs
>> >introduced are rapidly fixed.  I submit to you that this is not the case
>> >in reality from our own experience from 1.5.18 through 1.7, and is a
>> >nearly impossible goal, especially for a volunteer open source software
>> >project.
>> >
>> >For example, I'm aware of few times where our original application built
>> >and working under 1.5.18 did not have a significant issue with newer
>> >versions; many of which were complete show stoppers.  Some of these issues
>> >were due to policy changes that decided it was ok to break previous
>> >behavior because is was deemed to never have been "officially supported".
>> >Some were due to "bug fixes" that changed behavior to make it more like
>> >Linux, others were due to bug fixes that significantly effected
>> >performance, and still others were due to introducing new bugs when new
>> >features were added.  If anyone really wants the complete chronological
>> >list, I can provide it, but I don't think the details are where the point
>> >lies.
>> Of *course* we want details.
>Ok, I'll provide them to the best of my memory.  The fine details of which
>may take me a while to recall if you want further information.
>Policy changes:
>1.5.19 no longer synchronizes the Windows and Cygwin environment
>(cygwin_internal hook added in 1.5.20)
>1.5.19 high resolution timing no longer supported (timeBeginPeriod(1 ms)

I googled this and see you complaining about it.  It isn't exactly clear
what your complaint is or how it relates to a modern Cygwin.

It isn't clear that these aren't actually just bugs.

>Simple bugs:
>1.5.18 spawnve was broken
>1.5.19 nanosleep was broken
>1.7.x  deadlock with multiple threads accessing one socket (my fault, I
>haven't notified or provided a test case yet as this is arguably bad app
>behavior even though it worked in 1.5.18)
>Linux bug fixes:
>1.5.19 Added exe to /proc/self/exe
>Performance issues:
>1.5.19 I/O performance degraded severely due to signal handling fix
>http://cygwin.com/ml/cygwin-developers/2006-07/msg00029.html etc. mostly
>restored now in 1.7
>New feature bugs:
>1.5.20 MAP_NORESERVE not correctly implemented
>1.5.21 MAP_NORESERVE better, but no supported when passed as buffer to
>system calls
>Obviously the new feature bugs only affected new app builds.  Many
>temporary issues also existed with CVS versions, snapshots, and
>experimental releases as can be expected.
>I'm sure there are a few more that I don't recall or didn't document.
>IIRC, 1.5.25 was mostly ok except for I/O performance and 1.7.x is now ok
>except the threaded socket deadlock I mentioned above.  Overall, it
>doesn't look as bleak as I remembered, but it is a comedy of errors
>preventing upgrade due to the usual some bugs fixed, some bugs introduced
>problem.  Frustration tends to build when that persists for significant
>calendar time, but I understand this is a volunteer effort.
>>It is funny that you chose this particular discussion to make this
>>point, however.
>I don't understand this statement at all.  It seems particularly
>relevant to this discussion to me.

My point is that you waited years to mention what you consider problems
with backwards compatibility and then used this opportunity, where I
reiterate a standard cygwin policy, to say "Oh no it isn't!"

Most of the above are bug fixes however, which I would say proves my
point since you don't see bug fixes in 1.5.20 which permanently go away
in 1.5.21.

No one claims that there won't be problems with releases.  However you
could use the above to justify the "always use the latest version".  If
someone decided to package 1.5.20 then MAP_NORESERVE would be
permanently broken in their package until they realized the mistake.
The point of using the latest version is that we fix bugs as we find
them.  We don't fix bugs in versions of cygwin included with other
people's packages.

I'm obviously not saying that everything is always guaranteed to be
pristine and perfect in every Cygwin release.  There is, however, a
general trend towards improvment so it makes general sense for people to
use the latest version.  However, I've also repeatedly said that if
someone is responsible for a large installation that uses Cygwin they
would be daft (and I don't think you are) to just blindly install a new
version and trust that we have been keeping their specific needs in


More information about the Cygwin-developers mailing list