ports/65887: mutt and mutt-devel can silently depend on libiconv

Yar Tikhiy yar at freebsd.org
Fri Apr 23 10:10:21 UTC 2004


The following reply was made to PR ports/65887; it has been noted by GNATS.

From: Yar Tikhiy <yar at freebsd.org>
To: Udo Schweigert <Udo.Schweigert at siemens.com>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: ports/65887: mutt and mutt-devel can silently depend on libiconv
Date: Fri, 23 Apr 2004 14:03:55 +0400

 On Thu, Apr 22, 2004 at 04:55:13PM +0200, Udo Schweigert wrote:
 > On Thu, Apr 22, 2004 at 18:49:19 +0400, Yar Tikhiy wrote:
 > > On Thu, Apr 22, 2004 at 03:53:29PM +0200, Udo Schweigert wrote:
 > >> On Thu, Apr 22, 2004 at 17:32:57 +0400, Yar Tikhiy wrote:
 > > >>>Fix:
 > > >> 	An easy way is to add ``USE_ICONV=yes'' to the mutt Makefiles.
 > > >> 	A harder approach is to implement conditional dependencies
 > > >> 	within the ports framework, that is to let ports tell,
 > > >> 	"I could use the port foo if it were installed already;
 > > >> 	never mind otherwise."
 > >> 
 > >> One could also choose to use the --disable-iconv option of mutt's configure.
 > > 
 > > By itself it's more to amputation than to a solution :-)
 > > Mutt's using libiconv is a valuable feature for users whose native
 > > alphabet falls beyond Latin-1.  And specifying --disable-iconv would
 > > inhibit mutt from using libiconv even if it is installed. 
 > 
 > Isn't that a contradiction to WITHOUT_NLS?
 
 Not exactly.  AFAIK, WITHOUT_NLS controls using gettext for localized
 user interface and has effectively nothing to do with libiconv.
 The features are mutually orthogonal and can be used independently.
 For example, it may sound whimsy, but many Russian users, for whom
 I can speak as long as I'm one of them, hate interface localization
 because Russian translations of computer terms often look really
 weird and inconvenient.  Therefore they do not need gettext, while
 libiconv is of use to them so they can read mail coming in various
 Russian charsets.  I bet the same applies to a number of other
 national groups of users.  And even in general, two independent
 features should not be tangled up without a grave reason.
 
 -- 
 Yar



More information about the freebsd-ports-bugs mailing list