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 area - 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 state. Brian