ports/65887: mutt and mutt-devel can silently depend on libiconv
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.
More information about the freebsd-ports-bugs