Re: Connecting those interested in getting GT.M into the Debianrepositories
Comments below. Look for [KSB].
Andreas, I took your name off the addressee list to avoid duplication.
Alan, Jon and Mike, let me know if you want me to leave your names off.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 08/03/2010 02:11 PM, Andreas Tille wrote:
Hi Bhaskar,
in the end you suggested to move this discussion to the Debian Med list
- I simply decided that it is time to do so now (and hope you will not
mind the full quote of a mail I can not find private content in).
[KSB] That's fine. Thanks.
On Tue, Aug 03, 2010 at 11:00:22AM -0400, K.S. Bhaskar wrote:
[KSB] <...snip...>
> * Perhaps packages should be numbered such as
> fis-gtm_5.4-001A-3+lenny2_amd64.deb where 5.4-001A is the GT.M
> version, 3 is the third package of GT.M V5.4-001A, and it is built
> with the lenny2 toolchain for the amd64 architecture.
We need to target for unstable first and thus using lenny toolchain
doese not make any sense IMHO. Moreover my estimation is that we will
not finalise GT.M packages before Squeeze will be released - so
targeting at current unstable makes perfectly sense to me. Whether we
will be able to provide backports for stable distributions will turn
out later (probably reaslonable but increases the level of complexity
by one because of the bootstraping nature of GT.M build process).
[KSB] I agree that we should target Unstable first. Note that the
bootstrap requires a release of GT.M, not the current release of GT.M
(again like gcc bootstrapping - you can use an old release of gcc to
compile a new release of gcc).
> * Releases of GT.M should go into sub-directories of /usr/lib/fis-gtm.
Yes (except if there are large chunks of architecture independant data.
Than it should probably be a mix of /usr/lib/fis-gtm and /usr/share/fis-gtm
(symlinks to have all in /usr/lib are fine).
[KSB] The only architecture dependent data are binary files compiled for
the target architecture. So, we don't need anything in /usr/share/fis-gtm.
At some point when we create an fis-gtm-doc package for the user
documentation, that can go in /usr/share/doc/fis-gtm.
> * update-alternatives should be used to maintain multiple versions
> of GT.M on the system. I don't fully understand how this is
> configured. Perhaps fis-gtm itself should be a virtual package
> that always installs the latest GT.M on the system. /usr/bin/gtm
> could be a symbolic link (perhaps via /etc/alternatives) to
> /usr/lib/fis-gtm/<version>/gtm.
I do not know gtm enough to give an educated answer on this but starting
with /usr/lib/fis-gtm/<version>/gtm (perhaps without the final gtm
because it somehow seems to be redundant) seems to make sense anyway in
case you would like to run different versions at the same time. I'd
recommend adopting the scheme of postgresql
/usr/lib/postgresql/<version>/{bin,lib}
which uses a script
/usr/share/postgresql-common/pg_wrapper
to organise things. It turned out to be useful to have such working
examples in mind.
[KSB] Actually, /usr/lib/fis-gtm/<version>/gtm is a shell script that you
can run to execute GT.M, and /usr/lib/fis-gtm/<version> is the directory
that contains the entire release. The actual executable binary file is
called mumps. There are other binaries as well, the most important of
which are mupip, dse and lke.
Now that I think of it, there is a file that can be sourced to set up
environment variables /usr/lib/fis-gtm/<version>/gtmprofile. Perhaps
there should be a directory /etc/fis-gtm/<version>/gtmprofile which is a
relative symbolic link to /usr/lib/fis-gtm/<version>/gtmprofile.
> * Also, perhaps mumps should be a virtual package that installs
> fis-gtm, but could allow for other FOSS MUMPS packages in the
> future (they do exist; they're just not as mature as GT.M). Thus
> /usr/bin/mumps could be a symbolic link through /etc/alternatives
> to /usr/bin/fis-gtm.
The correct wording is: fis-gtm *Provides: mumps* (as well as other
potential FOSS MUMPS implementations). (A virtual package does not
install anything but is provided by real packages. Other packages
which depend from any mumps implementation would then
Depends: mumps | fis-gtm )
However, as far as we only have this single mumps implementation I
do not see any need to make things more complicated than needed for
the moment.
[KSB] OK
> We do have a potential issue with bootstrapping GT.M on alioth, the
> Debian build system. Building GT.M requires an executable GT.M for
> bootstrapping (the way that compiling gcc requires an existing gcc).
> So, it seems to me that we have to create a binary GT.M packages first,
> get them installed on alioth and then use the source package to build
> more binary packages.
We do not necessarily do this on alioth (I guess alioth admins will not
be keen on giving us root permissions). IMHO we can do the installation
on any local build machine and try to build the package. Than we have
to talk to ftpmaster how to precisely proceed.
[KSB] OK
> Note that GT.M has a component that is installed setuid root. I don't
> know if this requires special review by system administrators, but it is
> essential (see
>
http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_Security_Philosophy.html).
I guess it is sufficent if it is properly documented (for instance by
adding hint to /usr/share/doc/fis-gtm/README.Debian or quoting this link
there).
[KSB] OK
> GT.M requires a contemporary Linux 2.6 kernel, glibc, libncurses5, and
> the file packages. [I am not entirely sure how glibc is provided, but
> essentially GT.M needs the basic C runtime to exist.] It should
> recommend gnupg | gnupg2, libc-bin, libgcrypt11, libgpg-error0,
> libgpgme11, libicu-dev and zlib1g (strictly speaking, GT.M does not need
> libicu-dev; it requires libicu36 or newer; but libicu-dev is the best
> way to get the latest ICU, and GT.M uses the icu-config --version
> command which is part of libicu-dev rather than libicu<version>).
Prerequisites seem to be no problem.
> Apologies for the tardiness. And a special thank you to Alan for
> volunteering.
>
> At some point, we should probably shift move this discussion thread to
> the debian-med list.
I hope you agree with my public discussion.
Kind regards
Andreas.
--
http://fam-tille.de
_____________
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: