[pkgsrc/trunk]: pkgsrc/pkgtools/libnbcompat/files s/seperate/separate/; s/ind...

[snj <snj%pkgsrc.org@localhost>]

details:   https://anonhg.NetBSD.org/pkgsrc/rev/ebe69152fd2e
branches:  trunk
changeset: 467442:ebe69152fd2e
user:      snj <snj%pkgsrc.org@localhost>
date:      Sun Feb 01 00:07:56 2004 +0000

description:
s/seperate/separate/; s/independantly/independently/;
s/dependancies/dependencies/

diffstat:

 pkgtools/libnbcompat/files/aclocal.m4 |  8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diffs (24 lines):

diff -r 93bd6cd6152d -r ebe69152fd2e pkgtools/libnbcompat/files/aclocal.m4
--- a/pkgtools/libnbcompat/files/aclocal.m4     Sat Jan 31 23:57:54 2004 +0000
+++ b/pkgtools/libnbcompat/files/aclocal.m4     Sun Feb 01 00:07:56 2004 +0000
@@ -1,4 +1,4 @@
-dnl $NetBSD: aclocal.m4,v 1.2 2003/09/06 23:03:00 grant Exp $
+dnl $NetBSD: aclocal.m4,v 1.3 2004/02/01 00:07:56 snj Exp $
 dnl
 
 dnl
@@ -77,11 +77,11 @@
 dnl This test exists so that every application developer does not test this in
 dnl a different, and subtly broken fashion.
 dnl 
-dnl It has been argued that this test should be broken up into two seperate
+dnl It has been argued that this test should be broken up into two separate
 dnl tests, one for the resolver libraries, and one for the libraries necessary
 dnl for using Sockets API. Unfortunately, the two are carefully intertwined and
-dnl allowing the autoconf user to use them independantly potentially results in
-dnl unfortunate ordering dependancies -- as such, such component macros would
+dnl allowing the autoconf user to use them independently potentially results in
+dnl unfortunate ordering dependencies -- as such, such component macros would
 dnl have to carefully use indirection and be aware if the other components were
 dnl executed. Since other autoconf macros do not go to this trouble, and almost
 dnl no applications use sockets without the resolver, this complexity has not