It was pointed out to me that gmake is not a good example of a case where the man page lists a name different from the one delivered, since gmake is delivered as both /usr/bin/gmake and /usr/gnu/bin/make. Does anybody know of any other precedents in this regard?
So, in any case, we need a "best practice" kind of rule around FOSS man pages. Should the team attempt to deliver as close as possible to the original page in the package, or should it reflect the capabilities of what is actually delivered, or something in between? It was already pointed out that an "Attributes" section almost certainly must be added. In this particular case, it also seems likely that the synopsis needs to be changed to reflect the renamed deliverables, no? These two cases must be decided before this case goes forward. And in general, I believe that we require some kind of man page even if the original package didn't have one, right? What about other changes to the package, such as features not enabled under Solaris? Should these be left in, deleted, or flagged somehow as not applicable? If so, how? I feel pretty strongly that since the man page is the canonical source of documentation on commands in Solaris, that these pages must reflect how the world is, and not how we would like it, or expect it to one day be. To me, that is juts part of the porting procedure. Like the old poster says, the project isn't done until the paperwork is finished. But then, that is just me. What do the rest of you feel? -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
