Re: Connecting those interested in getting GT.M into the Debian repositories
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).
On Tue, Aug 03, 2010 at 11:00:22AM -0400, K.S. Bhaskar wrote:
> The primary purpose of this e-mail is to connect those interested in
> getting GT.M into the Debian repositories. It is clear that if we wait
> for me to do it, it will tax the patience of all.
>
> * Andreas Tille is one of the movers and shakers of Debian Med and
> has been interested for years in getting GT.M packages into the
> Debian repositories.
> * Alan has expressed willingness to lead the effort. Andreas has
> expressed interest in providing guidance from the Debian perspective.
> * Jon Tai and Mike Clayton have built Debian packages from GT.M
> source tarballs released at Source Forge by FIS. Source Forge
> would be the upstream source for GT.M in the Debian repositories
> and FIS would be the upstream developers. I hope Jon & Alan can
> assist Alan with building GT.M (at least with advice).
> * Ignacio has created GT.M Debian packages from the binary tarballs
> released at Source Forge by FIS, but I think his interest is
> primarily in being a user of a GT.M Debian package for his
> Astronaut VistA rather than a builder of one. (Ignacio is also
> interested in Fedora rpms, but we won't go there in this discussion!)
Good summary.
> Here are some thoughts on the high level structure.
>
> * The package name for GT.M should (I think) be fis-gtm.
OK
> * 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).
> * 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).
> * 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.
> * 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.
> 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.
> 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).
> 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
Reply to: