> There is a problem with parts of the files. For example the tree > contains usr/src/lib/libshell/common/sh.1 which is the unmodified ksh93 > manual page which exactly matches the status of the current codebase in > OS/Net while the one (ksh93.1) which is going to be shipped with Solaris > is a hightly customized version. Removing the "sh.1" file would be > possible but we would loose the documentation to the current code since > the Solaris "ksh93.1" manual page would follow the ARC cases and > therefore may likely a few months behind the one in the tree and/or list > features which are optional in the official version (like C99 math > functions or SCTP support).
First, documentation is generally not subject to the same sort of rules. You'll note that findunref already contains a blanket exception for text files and READMEs. Second, if the source file can reasonably be argued to have value on Solaris, then it's fine. However, a directory filled with (e.g.) Windows NT specific files would be hard to argue for. > ... but maybe I am worrying too much... the "findunref" list > lists "perl" and that may be a good precedent for ksh93... or not ? As I mentioned in an earlier email, we generally grant exceptions for parts of the source tree that are kept in-sync with an upstream source. But the exception should not be used to stockpile support for non-Solaris platforms provided that the files could be automatically pruned from the upstream source without too much effort. -- meem
