Re: pkg/21040 (libintl management in packages)

[Quentin Garnier <cube%cubidou.net@localhost>]

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

From: Quentin Garnier <cube%cubidou.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: joerg%netbsd.org@localhost
Subject: Re: pkg/21040 (libintl management in packages)
Date: Wed, 4 Oct 2006 14:03:02 +0200

 --0OAP2g/MAC+5xKAE
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Oct 04, 2006 at 11:45:02AM +0000, Joerg Sonnenberger wrote:
 > The following reply was made to PR pkg/21040; it has been noted by GNATS.
 >=20
 > From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: pkg/21040 (libintl management in packages)
 > Date: Wed, 04 Oct 2006 13:37:55 +0200
 >=20
 >  On Mon, Oct 02, 2006 at 09:40:02PM +0000, Quentin Garnier wrote:
 >  >  Could you please at least read the contents of the PR?  In that case =
 it
 >  >  was the issue of gettext not being able to parse UTF-8 locales.  AFAI=
 CT,
 >  >  pkgsrc doesn't work around that issue.  And there is no way for the u=
 ser
 >  >  to know about the issue until a number of packages are already built,
 >  >  which is even more of a pain.
 > =20
 >  *sigh* Yes, I give that back. The problem mentioned and discussed is
 >  specific to the locale settings and message catalogs used by programs.
 >  The newer libintl versions support automatic conversion -- the older
 >  don't. The problem mentioned was related to including gettext.b3.mk,
 >  and whether or not the pkgsrc version is used depends on PREFER_PKGSRC.
 >  There is no notion of "application wants to have magic UTF8 conversion",
 >  since that's an optional feature and could be handled by converting the
 >  message catalogs before to all desired locales. So again, this is *not*
 >  application specific and we *do* have the mechanism to handle it.
 >  Given that UTF8 locales without working iconv will create more than
 >  enough problems anyway, I don't consider this a typical setup of unaware
 >  users and more a regression of older NetBSD releases. In that sense, it
 >  is a documentation issue for those.
 
 You don't see the big picture here.
 
 Application A wants feature F from library L, and depends on library L1,
 which needs L too, but not feature F.  System provides L without F.
 When L1 is built, L from system is used.  When A finally gets built,
 there are two choices:  either it uses system's L, but then it breaks
 because F fails, or it depends on pkgsrc's L, but then it also breaks
 because unless some hard magic is worked, system's L will be loaded
 through L1.
 
 When exactly does the user get to have an opinion here?  If the user
 just wants A and is told about the issue, then working around it is
 possible.  But L1 might have already been built for application B that
 doesn't need F, before the user ever realised s/he wanted to install A.
 
 And what exactly is the meaning of "regression of older release"?  Note
 that when I filled that PR, it wasn't quite an older release.  And this
 is something we can experience in X land any day, you know.
 
 The precise issue in the PR is not tied to iconv, but really to libintl:
 gtk+ depended on libiconv at the time because UTF8 is part of the API,
 the problem was that libintl simply failed to load locale files written
 in that encoding.
 
 Again, the NetBSD release at stake will eventually get EOL'd, rendering
 this PR obsolete, but the issue will not have been addressed.
 
 --=20
 Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
 "You could have made it, spitting out benchmarks
 Owe it to yourself not to fail"
 Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
 
 --0OAP2g/MAC+5xKAE
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.3 (NetBSD)
 
 iQEVAwUBRSOi9tgoQloHrPnoAQKwBAf/Q317MhC9jlE+9817EQUmhaNsQWMMZnhj
 0yhEfPQaSHogbkcpt5z5DG6+cHQltppiArR3SRROYkOQ/e089D3gPAADTwmFSAlT
 Yh04lRkCgoeDTgST9iWXLMg63VzaW7+o+A0BSi5cU0vWHZr2qF68V8IblAIzfBxO
 Jk9LTUXmXljTo+YSYfHLJxlPB89zBor+xlnpWK0EES3euDwzVqABXq33eytex0hY
 AHdehlnBoqyikbt5ytZFJ6nC03Oaa3HIAZJKCpFzzGiPHzUbpNbPPndQ2KC/GplK
 HjYo3K6uzZj9esi8t78kDTo3FBlvkIL2RyjaA4oyQ3Zr250MVdsSZA==
 =n/3m
 -----END PGP SIGNATURE-----
 
 --0OAP2g/MAC+5xKAE--