I am catching up on e-mail and will try to respond to all the issues thoughtfully discussed by Andreas and Alan in this single response.
Preference for no root owned files in the .deb distribution files: I have a preference for not including any files owned by root in the .deb distribution files. This makes it easy for anyone who wants to analyze a package to be able to unpack it without needing root access. Since I often need to run 32-bit executables on a 64-bit Linux, I find I need to often need to take apart packages and it is an inconvenience to need root. Use of bin: GT.M itself makes no assumptions about the ownership of the files, and offers bin as the default for historical reasons and because the same install script is used for all GT.M on all UNIX/Linux flavors. GT.M itself is quite happy for the installed distribution to be owned by root. There is an installation option to restrict the execution of GT.M to members of a group. I suggest that the default for Debian is to not so restrict it, but to provide the option (for those who choose the "ask me everything when installing packages" installation option) to prompt for installing it so restricted. Note that the gtmsecshrdir directory must be owned by root with permissions to only allow access by the owner (not even group). It contains one file, gtmsecshr that is owned by root and readable and executable only by the owner, not even group and with the setuid bit on). The parent directory also has a file called gtmsecshr, which must be owned by root and be readable and executable by the owner with the setuid bit on. This outer gtmsecshr file has the same group as all other GT.M files and it's world read and execute permissions can be turned off if GT.M access is restricted to a group. Incidentally, there is no assumption that bin is uid 2 (and symbolic names are preferred over numeric ones anyway). 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. The prerm script can make files writable for removal, or the remove script can use a -f flag to override. .o files: .o files are object files compiled from .m source files. There are two types of .o files - those that are considered part of GT.M itself that are written in M and those that are utility programs written in M. The former is the utility program GDE. Since it is considered part of GT.M itself and generates a binary image of a data structure that is loaded into RAM, our normal GT.M binary distributions do not include the source code (of course, the source tarball does). The source code for the utility programs is included with the binary distributions to allow users to adapt and customize. The concept of a "single user" GT.M is not meaningful. GT.M is inherently multi-user. However, individual databases can be single- or multi-user. The script "gtm" and the file gtmprofile that can be sourced - their use is optional since the entire operation of GT.M is controlled by environment variables - looks for an environment variable $gtmdir and defaults this to $HOME/.fis-gtm if it is not defined. Alan, please do not link the FIS provided gtm script with the name gtm-su. gtm is the upstream name for the script, and if you override it, you run the risk of causing problems for someone who comes after you. I realize that you have independently created your own personal "gtm" script. I am sorry if I sound hard-hearted, but it is better for you to bear a little one-of pain than to institutionalize something that will keep causing headaches in the future. 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. So I recommend making GT.M depend on libicu-dev with a version of 3.6 or greater. [Note that use of GT.M for languages with 8-bit characters, such as with ISO-8859 family representations does not need ICU, and therefore in theory libicu / libicu-dev can be 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.] Source tarballs: the same source tarball is used to build both the 32- and 64-bit executables. Note that GT.M compiler's code generator is very different internally for the two, but we only release one source tarball from which you can build both binaries. GT.M versions: I see no reason to package anything other than the latest, V5.4-001. Once we establish (Alan establishes) a process for creating GT.M Debian packages from upstream releases, then future releases will slide into place! Bootstrapping GT.M: this was previously discussed, and I am not sure I have anything profound to add. I think I have responded to all the issues. If I have overlooked any, please let me know, and I will respond tomorrow (Tuesday, September 7, US Eastern time). Thanks Alan and Andreas for all your efforts. Regards -- Bhaskar GT.M - Rock solid. Lightning fast. Secure. No compromises. _____________ 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. _____________
