On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:

> 
> While adding a normative statement reference in chapter one for
> specifications, I noticed the section on "related implementations" where
> mention is made of the following:
> 
> * BSD BSD 4.4 Lite version 2 (no URL)
> 
>       We really should get a URL for this.... anyone know of a stable
>       one off-hand.  Also, these functions should probably get
>       documented first when we start the LSB 1.1 effort, since I'm
>       concerned about "code drift"; it's been a long time since BSD
>       4.4 Lite, and the library interfaces may have changed in subtle
>       ways since then.

Agreed.

> * GNU/Linux defacto standard  http://www.gnu.org/
> 
>       This is a bit too broad; if we mean "glibc" or "bash" we should
>       say so, and then specify exaclty which version we mean.
> 
>       I'd also just as soon avoid the whole GNU/Linux vs. Linux
>       religious argument if at all possible.  Note that as far as I
>       can tell although baselib/libc lists "GNU/Linux defacto
>       standard", none of the symbols actually reference the footnote
>       number corresponding to it, at least on the verison that's
>       currently up at www.linuxbase.org.  The only place that
>       referenes this is setresgid/setresuid in the usergroups
>       section. 

This is intentional. It is all of these things that we have to document
in the LSB itself since there often isn't a real specification to back
these up. Stuff covered by POSIX, SUS, et al is attributed to that standard
so only left-over stuff would be attributed to this reference implementation.


> * RPC & XDR   RFC 1831 & 1832         http://www.ietf.org
> 
>       This reference is certainly wrong, since it's not an API
>       reference and never pretended to be.  We should probably
>       reference the comp.source.misc Sun posting of SunRPC, or just
>       simply reference a specific glibc version for now, since that's
>       what we're actually using.  

I've been asking for 2 years for an API description 8-), but no one seems
to have one. If we follow our rules strictly, we should yank all RPC related
interfaces because of this.


                                Stuart

Stuart R. Anderson                               [EMAIL PROTECTED]

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team
Creative Applications Lab Chair - SIGGRAPH 2001

Reply via email to