[HEADSUP] Start of Cygwin 1.7 release cycle

Brian Dessent brian@dessent.net
Tue Apr 15 03:32:00 GMT 2008

Andrew Schulman wrote:

> (1) Do all packages that include compiled code need to be rebuilt for Cygwin
> 1.7?  IOW, is ABI compatibility broken from 1.5?  Also, I presume that there
> would be no need to rebuild any packages that don't include compiled code, e.g.
> packages that depend only on Perl or Python.

No, it should be fully ABI backwards compatible, it's just that
recompilation will be required to enable the new features.  For example
if the app allocated its path buffers based on PATH_MAX (260 in 1.5,
4096 in 1.7), it will not be able to take advantage of long pathnames
even if the DLL would support it.

And likewise for ipv6 support, fopencookie, etc.  Those features would
not have been detected by the package's configure script and thus
disabled in 1.5, but they would be detected and enabled when rebuilt
against 1.7.  And it's that fact (new codepaths exposed in the app) that
needs testing.

> (2) If I understand right, the implication here seems to be that although Cygwin
> 1.7 will support the above features, it's going to be up to us package
> maintainers to ensure, or at least just test, that our packages support them
> too.  But, there seems to be no requirement about that.  That is, we could just
> dump our packages as they are into Cygwin 1.7, and not test them for any of the
> new supported features, assuming our consciences allow this.  Correct?

Well, part of the implication of the above is that some packages might
not build against 1.7 without tweaks.  For example I recently tracked
down a configure issue in autogen where it assumed the BSD signatures of
the types used with funopen(), which differ from the implementation in
newlib.  funopen/fopencookie didn't exist in 1.5 and are new in 1.7, so
these issues would have never been exposed when building the package
against 1.5, but the new feature exposed the codepath in autogen that
tried to use funopen, which needed some tweaks to work with Cygwin.

In my completely unofficial opinion I'd say that it's always at the
maintainer's judgement how to deal with these things.  In most cases if
a feature does not work you can simply disable it by configuring with
--disable-foo, or e.g. in the case of autogen by configuring with
"ac_cv_func_fopencookie=no ac_cv_func_funopen=no ./configure ..." forced
those features to be disabled since the configure tests were broken. 
But ideally it would be best if whatever compatibility problems arise
can be dealt with so that the package builds as close to OOTB as
possible, and so that the new functionality is enabled in the app.

> (3) For packages that have been tested, are we going to have a standard and/or
> common location or format in which to put our "tested against Cygwin 1.7/tested
> for long file name/UTF-8/IPv6/etc. support" results?  Or just note the results
> or not in our README.Cygwin files?  The latter seems fine to me, I'm just
> wondering.

I can't speak for anyone else but the way I invisioned this working is:

- maintainer uploads 1.7-built package to the 1.7 release area
- other 1.7 testers install it in their 1.7 tree
- problems are reported to this list
- maintainers fix the issues, upload updated packages to the 1.7 release
- after sufficient iterations of this, the 1.7 area is declared ready
for prime time, and is switched over to the default distro instead of
being a sandboxed area

Of course if you want to note in the README.Cygwin the changes/tweaks
that were necessary for each package bump, that would probably help
everyone.  But the fact that the package exists in the 1.7 area at the
time that it goes live would be the main indicator that it's passed
somebody's definition of (at least minimal) working.  In other words, if
there's some really hairy unsolvable problem with a 1.7-built package,
it should be removed from the 1.7 area and the old 1.5-built version
used until the problem is fully resolved.

> (4) It seems that it might be useful to develop standard unit tests for some of
> these features.  Long file name support is simple enough-- we just have to
> create some path names longer than 260 characters, and try feeding them to our
> applications.  But for UTF-8 and IPv6 support, it could take each of us a lot of
> time to work out tests on our own.  Or at least, it would take me a while since
> I'm mostly ignorant of them...  A standard, documented approach would sure help
> me, and maybe other packagers too.  I freely admit though that I am not
> volunteering to do this.

Yes, I'm sure all of those things would be helpful.  We don't have to be
perfect either.  We should be realistic in that the number of people
that are clued enough to monitor this list and download a separate
setup.exe and follow the steps to install an experimental distro is
going to be much smaller than the general userbase of Cygwin, so we
won't be able to suss out every problem before the 1.7 area goes live. 
I think that's fine, we just need to get things into a good enough


More information about the Cygwin-apps mailing list