From owner-freebsd-current@FreeBSD.ORG Wed Apr 23 17:27:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B8C637B401; Wed, 23 Apr 2003 17:27:42 -0700 (PDT) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078AE43F93; Wed, 23 Apr 2003 17:27:42 -0700 (PDT) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id F06DE9C81; Wed, 23 Apr 2003 20:12:57 -0400 (EDT) Date: Wed, 23 Apr 2003 20:12:57 -0400 From: Mike Barcroft To: Daniel Eischen Message-ID: <20030423201257.A36743@espresso.bsdmike.org> References: <20030423133153.A35731@espresso.bsdmike.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from eischen@pcnet1.pcnet.com on Wed, Apr 23, 2003 at 02:08:40PM -0400 Organization: The FreeBSD Project cc: Daniel Eischen cc: current@FreeBSD.org Subject: Re: Multiple (same) sets of man pages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 00:27:43 -0000 Daniel Eischen writes: > On Wed, 23 Apr 2003, Mike Barcroft wrote: > > > Daniel Eischen writes: > > > [ doc@ bcc:'d ] > > > > > > With 3 threading libraries, each with a set of the same man pages, > > > how should this be handled? It doesn't make any sense to have > > > all of them installed and yet it should still be possible to > > > install all 3 thread libraries. > > > > > > Do we need a different heirarchy for threads? > > > > Ideally, they'd all document the same specification. Perhaps there > > Right, but there may be extensions in some that aren't in the > others. So those would be library-specific man pages. Like > pthread_switch_{add,delete}_np() that I believe is only supported > in libc_r. I have no plans on supporting it in libpthread > since it really doesn't make sense there. There will also be > other functions available in libpthread that aren't in libc_r > (and perhaps libthr). I think you could still share the documents and use the LIBRARY section to document which thread libraries support a given function. Best regards, Mike Barcroft