at this moment, there are so many userland tools that depends upon
	libintl from GNU gettext, and many of pkgsrc tools depends opon it.

	we, at Citrus project (which develops multilingual librarires),
	have GNU gettext-compatible libintl library, under BSD license.
	it will eat GNU *.mo message catalog files and manipulates handles
	them accordingly.  i have been using it for supporting GNU grep and
	some other GNU applications, with no problem.  Citrus project plans
	to extend the internals of the library in the near future (for tighter
	integration with other libc multilingualization stuffs), but even in
	the current form, it works just fine as GNU libintl.a replacement.

	do people think it a good idea to bring it in?  if we do so, we can
	nuke most of the pkgsrc dependencies to pkgsrc/devel/gettext
	(which is necessary for libintl only, not for other gettext-related
	userland tools).  we still need pkgsrc/devel/gettext for catalog
	file compiler and other stuffs.  (it may be a good idea to bring it
	into gnu/dist/gettext and put reachover makefiles, but that is another
	issue).

	the other way to solve this issue is to split pkgsrc/devel/gettext 
	into two portions - gettext-lib and gettext.

	to summarize:
	- problem: too many pkgsrc dependency to libintl.  they are basically
	  just for libintl.
	- solution 1: split pkgsrc/devel/gettext into gettext and gettext-lib
	- solution 2: bring in BSD-licensed libintl compatible library into
	  basesrc/lib/libintl.  we will be doing it anyways in the near future
	  for libc multilingualization.
	- solution 3: do both.

itojun