Hi Andreas,
I'm happy to see that this discussion is continuing, and I'm still
interested in finding a way to get this package built. I'm currently
doing some digging to see if I can find a way to do it. Since I'm
sailing in uncharted water (at least not charted by myself :) ,it's
difficult to predict the outcome, but I just wanted to say that I'm
still "on the job." As I discover things that are worth sharing or find
questions for which I think you may know the answer, I'll surely be in
touch.
Alan
On 09/08/2010 01:50 AM, Andreas Tille wrote:
On Tue, Sep 07, 2010 at 04:51:48PM -0400, K.S. Bhaskar wrote:
IMHO as long as you are dealing with peoples names you always have to
respect non-ASCII characters even in pure English environments.
[KSB] In the United States, it is common to pretend that there are no
non-ASCII characters in names.
So a lot of immigrants are not spelled properly ... hmmm.
There are only "Build-Depends" (and no Build-Recommends) - so this is
simple.
[KSB] I am a little confused as to what this means in practice. Building
GT.M will require ICU (libicu-dev), but this is so that the binaries can
use ICU if it is installed. Running GT.M does not require ICU unless an
application wants to use UTF-8.
If you Build-Depend to libicu-dev and it happens that some binary file
in the resulting binary package depends from symbols provided in libicu*
then the control file variable
Depends: ${shlibs:Depends}
will be expanded apropriately by the package building tools
automatically. Only if libicu* provides stuff which can not be
automatically detected (and thus is not required) you need to mention it
explicitely and thus have a choice between Recommends and Depends. So
most probably the discussion about this is moot anyway because the
packaging tools are supposed to handle this properly anyway.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8a20a4.1070...@cavtel.net
