Re: Connecting those interested in getting GT.M into the Debianrepositories
On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > Writabilty of files: I prefer for an installed version of GT.M to not > have *any* writable files, even if root-owned and only owner-writable. How does GT.M persist data ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20100907115300.gb2...@hermes.hilbert.loc
Re: Connecting those interested in getting GT.M into the Debianrepositories
On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > The concept of a "single user" GT.M is not meaningful. GT.M is > inherently multi-user. Well, one needs to keep apart the concepts. Of course, the database engine itself is (like PostgreSQL) inherently multi-(DB)-user and will always make it possible for several (DB)-users to connect if so configured. Nonetheless it need not be installed in a *systemwide* way but could conceivably also be installed in a way local to a specific *system* user and with system level file permissions restricted to said system account. Of course, even that instance will allow multiple DB users to access but from the point of view of the system user this is a single-user, "private", "local" installation -- all DB users semantically map to the one system user. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20100907120326.gd2...@hermes.hilbert.loc
Re: Connecting those interested in getting GT.M into the Debianrepositories
On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > Unicode version: GT.M itself requires ICU version 3.6 or higher. > However, 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. Indeed. Does this not ask for either a meta-package "icu" or a "Provides: icu" in each of the libicu's ? Andreas ? OTOH, Debian Squeeze comes with at least libicu42. > recommended rather than required. However, anyone today starting to > write a new application today, and using ISO-8859 character sets that > use the high order bit is asking for trouble when internationalizing > tomorrow, is asking for trouble. So, it may be better to just require ICU.] +1 > GT.M versions: I see no reason to package anything other than the > latest, V5.4-001. +1 Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20100907120931.ge2...@hermes.hilbert.loc
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 libicu. 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. However, > 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 useful > 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 immediate problem with the naming scheme anyway. Furthermore, the dependancy on packages like libicu36 are machine-inserted at build time. As you noted, the development package itself does not have a version number encoded in its name. Therefore, 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 libicuyz 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). Regards -- 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. _ -- 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/4c864428.2040...@fisglobal.com
Re: Connecting those interested in getting GT.M into the Debianrepositories
GT.M - Rock solid. Lightning fast. Secure. No compromises. On 09/07/2010 07:53 AM, Karsten Hilbert wrote: On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > Writabilty of files: I prefer for an installed version of GT.M to not > have *any* writable files, even if root-owned and only owner-writable. How does GT.M persist data ? [KSB] GT.M itself is the database engine and persists data in database files. GT.M makes no restrictions on where database files can live - the operation of a GT.M process is entirely controlled by environment variables. So an application using GT.M would ensure that processes would have environment variables set correctly. The database engine does generate temporary files and log files (which are also pointed to by environment variables in the process' environment). So GT.M itself can and should be installed read-only by the package (in /usr/lib/fis-gtm/). GT.M's own defaults are for $gtm_tmp to point to /tmp/fis-gtm/ and $gtm_log to point to /var/log/fis-gtm/), but these are easily overwritten by a system administrator (either by editing a file that is sourced to change the defaults, or to provide alternative values for environment variables). Regards -- 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. _ -- 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/4c8647d4.80...@fisglobal.com
Re: Connecting those interested in getting GT.M into the Debianrepositories
GT.M - Rock solid. Lightning fast. Secure. No compromises. On 09/07/2010 08:03 AM, Karsten Hilbert wrote: On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > The concept of a "single user" GT.M is not meaningful. GT.M is > inherently multi-user. Well, one needs to keep apart the concepts. Of course, the database engine itself is (like PostgreSQL) inherently multi-(DB)-user and will always make it possible for several (DB)-users to connect if so configured. Nonetheless it need not be installed in a *systemwide* way but could conceivably also be installed in a way local to a specific *system* user and with system level file permissions restricted to said system account. Of course, even that instance will allow multiple DB users to access but from the point of view of the system user this is a single-user, "private", "local" installation -- all DB users semantically map to the one system user. [KSB] The GT.M engine itself doesn't care where it is installed. A GT.M process requires that the $gtm_dist environment variable point to the directory where it is installed. Indeed, you can have the exact same version of GT.M installed in two locations in the file system, and they can operate completely independently of each other - the processes using each installation would have appropriate values of $gtm_dist, $gtm_log and $gtm_tmp. Regards -- 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. _ -- 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/4c864938.5040...@fisglobal.com
Re: Connecting those interested in getting GT.M into theDebianrepositories
On Tue, Sep 07, 2010 at 09:54:48AM -0400, K.S. Bhaskar wrote: > [KSB] Thank you, Charles. This is is a handy feature that I was not > aware of! Debian is cool, isn't it? ;-) > The first question is: should the GT.M package require ICU (International > Components for ICU) or should it recommend it? We would simply trust your decision. If you consider GT.M as dependant from libicu we use Depends. However, a Recommends is de facto quite strong. If a user does not explicitely exclude recommends these packages will be installed anyway. So you should probably answer the question: Can you imagine any real application where GT.M should run without libicu. If the answer is yes, use Recommends to give the admin a chance to avoid libicu. For all practical cases a Recommends is sufficient. > 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. IMHO as long as you are dealing with peoples names you always have to respect non-ASCII characters even in pure English environments. > The second question is: for ICU support, should GT.M require or recommend > libicu## or should it require or recommend libicu-dev? There are only "Build-Depends" (and no Build-Recommends) - so this is simple. Kind regards Andreas. -- http://fam-tille.de -- 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/20100907201816.gc20...@an3as.eu
Re: Connecting those interested in getting GT.M into theDebianrepositories
On Tue, Sep 07, 2010 at 10:18:16PM +0200, Andreas Tille wrote: > IMHO as long as you are dealing with peoples names you always have to > respect non-ASCII characters even in pure English environments. Indeed. That would pretty much decide it for me. Experience from GNUmed speaks to the same effect. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20100907203700.gr2...@hermes.hilbert.loc
Re: Connecting those interested in getting GT.M intotheDebianrepositories
GT.M - Rock solid. Lightning fast. Secure. No compromises. On 09/07/2010 04:18 PM, Andreas Tille wrote: On Tue, Sep 07, 2010 at 09:54:48AM -0400, K.S. Bhaskar wrote: > [KSB] Thank you, Charles. This is is a handy feature that I was not > aware of! Debian is cool, isn't it? ;-) [KSB] Yes, indeed! > The first question is: should the GT.M package require ICU (International > Components for ICU) or should it recommend it? We would simply trust your decision. If you consider GT.M as dependant from libicu we use Depends. However, a Recommends is de facto quite strong. If a user does not explicitely exclude recommends these packages will be installed anyway. So you should probably answer the question: Can you imagine any real application where GT.M should run without libicu. If the answer is yes, use Recommends to give the admin a chance to avoid libicu. For all practical cases a Recommends is sufficient. > 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. [KSB] All VistA implementations in the United States are pure ASCII. 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, for example, umlauts are usually dropped in favor of the letters without umlauts (I would prefer them to insert an "e" but we don't do that - e.g., we spell the city Zurich and not Zuerich). But, OK, I understand - GT.M should recommend ICU, and not depend on it. Also, most Linux systems outside the US (and maybe other English speaking countries) will probably have ICU installed anyway. > The second question is: for ICU support, should GT.M require or recommend > libicu## or should it require or recommend libicu-dev? 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. Regards -- 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. _ -- 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/4c86a5e4.3010...@fisglobal.com
Re: Connecting those interested in getting GT.M intotheDebianrepositories
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.
--
http://fam-tille.de
--
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/20100908055052.ga8...@an3as.eu
Re: Bug#595958: ITP: paml -- Phylogenetic Analysis by Maximum Likelihood
Hi Steffen, thanks for the ITP. As you can see at http://debian-med.alioth.debian.org/tasks/bio#paml this package is also provided by BioLinux people and I'd regard this as a really cool first step to integration if you would involve the maintainer inside BioLinux in the official Debian packaging. I'd imagine that he and you are mentioned as Uploaders in a Debian Med group maintained package and you work as sponsor of him. Kind regards Andreas. On Tue, Sep 07, 2010 at 05:54:13PM +0200, Steffen Moeller wrote: > Package: wnpp > Severity: wishlist > Owner: Steffen Moeller > > * Package name: paml > * URL : http://abacus.gene.ucl.ac.uk/software/paml.html > * License : academics only > Description : Phylogenetic Analysis by Maximum Likelihood > > PAML is a package of programs for phylogenetic analyses of DNA or protein > sequences using maximum likelihood. It is maintained and distributed for > academic use free of charge by Ziheng Yang. > PAML is not good for tree making. It may be used to estimate parameters and > test hypotheses to study the evolutionary process, when you have > reconstructed trees using other programs such as PAUP*, PHYLIP, MOLPHY, > PhyML, RaxML, etc. > -- http://fam-tille.de -- 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/20100908060411.gb8...@an3as.eu
