[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Connecting those interested in getting GT.M into theDebianrepositories

GT.M - Rock solid. Lightning fast. Secure. No compromises.

On 09/07/2010 12:59 AM, Charles Plessy wrote:
Dear Bhaskar,

here are two short comments about unpacking binary packages and
dependance on

Le Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar a écrit :

[KSB] <...snip...>

 > Unicode version: GT.M itself requires ICU version 3.6 or higher.
 > there is a defect in the way Debian packages ICU, by putting the
version number
 > in the package name (e.g., libicu36).  So, there is no way to define a
 > dependency for GT.M of version 3.6 or greater.  Also, there is a very
 > program icu-config that is part of libicu-dev rather than libicu.

Currently, the lowest version of ICU in Debian is 3.8, so there is no
problem with the naming scheme anyway. Furthermore, the dependancy on
like libicu36 are machine-inserted at build time. As you noted, the
package itself does not have a version number encoded in its name.
the GT.M source package can build-depend on libicu-dev ( >= w.x ), where
w.x is
what GT.M needs, and the binary package will automatically depend on a
package determined from the analysis of the symbols used by the GT.M binary
packages, and a file contained in libicu-dev listing in which version of the
library they were introduced.

[KSB] Thank you, Charles. This is is a handy feature that I was not aware of!

The first question is: should the GT.M package require ICU (International Components for ICU) or should it recommend it?

The reason for recommending ICU but not requiring it: for people developing applications that are strictly ASCII based (all characters in all strings that the applications handles are single byte with the high order bit 0), ICU support is unnecessary overhead. For applications that are pure English can use pure ASCII and not care.

The reason for: if ICU is not required, those developing applications that are not pure ASCII may be tempted to use ISO-8859 variants that have the high order bit set to 1 instead of using UTF-8. Given that there is not a single ISO-8859 variant that works for all European languages, if there are applications that use languages other than English, requiring ICU encourages those application developers to use a better character encoding.

My preference is to require ICU, but it is not a strong preference. Since many people on this list live in Europe, their views on ISO-8859 vs. UTF-8 should be considered. [For languages outside European languages, the case for UTF-8 is overwhelming.]

The second question is: for ICU support, should GT.M require or recommend libicu## or should it require or recommend libicu-dev?

My preference is to require or recommend libicu-dev, since that package includes the useful program icu-config which one of the GT.M scripts uses if available (icu-config --version reports the ICU version).

-- Bhaskar


The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

Reply to: