DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer
         :content-transfer-encoding;
        b=BT0fgGeisM64VJvsuCDieDEKxbq3/UkypMoKTD5/XeGjp5IEubLSPF3VVd5AfRHFna
         cOrt/K3iFr6pvUORCo4hteI2QC6gabYQSjnjMovfISyBedwhOsW1OHSU/tO3w8aQiv6f
         ctF1ZvbeqjumYRlyx28LHyXDYYV3+hk3L7eIk=
Subject: [alpine-devel] dealing with iconv
From: Natanael Copa <natanael.copa@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain
Date: Mon, 09 Feb 2009 15:44:15 +0100
Message-Id: <1234190655.11678.61.camel@nc>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

Problem:
Some packages needs iconv.
If iconv is installed will other packages just use it by default, even
if you are not asked for it. Sometimes its poissble to disable it with
--disable-nls, but I'm not sure that always works.

Result is that tons of packages will link to this bloaty lib. (gcc
included)

In gentoo days we just said: "you need iconv? sorry. not supported". In
some occations (vlc) I added uiconv to sources list, compiled it and
installed it (the .a and .h only) in temp area and used this with
--with-libinconv-prefix. The result was that my tiny uiconv got compiled
statically with the binary. 

Only utf-8, iso-8859-1 and ascii was is supported in uiconv.

In some cases it might be that we want the GNU iconv to support all
kinds of wierd charsets.

I wonder how we should deal with this.

Alternative 1:
we install GNU iconv in /usr/gnu-iconv and ucivon in /usr/uiconv. No
iconv is found by default and packages can select what iconv they want
by specifying --with-uiconv-prefix. (this didnt work in pinentry)


Alternative 2:
we install uiconv in /usr. It will be the "system default" iconv
implementation. We could install the .so too, but i think we generally
want to use the .a (static) version only.

GNU iconv can still be installed in /usr/gnu-iconv and packages who
wants it can install it with --with-libiconv-prefix. Not sure how to
deal with the shared libiconv.so as it woudl be needed in LD_PATH. If
there is only 1 single package that wants iconv (glib) then we might
want link that statically too.

Alternative 3:
we install GNU libiconv as the default iconv (--prefix=/usr) and uiconv
can be installed in /usr/uiconv/{include,lib} If we want that a package
should use a smaller iconv, they will have to set
--with-uiconv-prefix=/usr/uiconv.

We would need to have support for makedepends="!libiconv" or need to be
careful that we don't build with libiconv support by mistake.

Alternative 3.5:
Packages that needs iconv but is ok with uiconv can download, compile
and link to uiconv statically. (like pinentry does now and vlc does in
old build env)

What do you think?

Other ideas?

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---