GT.M .deb was RE: VistA comments
Hello Andreas,
For the record, I am an systems analyst working for a large regional
hospital. I don't pretend to be a clinician or to truly understand all of
the ins and outs of this particular system. Our core hospital system is
supported by mainly clinicians that we have send to some technical training
to support the product. I have been trying to introduce VistA for a couple
of reasons but I have clinicians working with me that are trying to
understand some of it.
You were talking about possibly 11 or more hardware architectures that
Debian supports and needing to package for that many. I am not certain that
will be necessary since GT.M is only GPL for x86 Linux platform. Sanchez
Associates sells the product for OpenVMS, AIX and other platforms. AFAIK,
no one has tried to port GT.M to any of the other Linux architectures. The
source is available, but I don't think that you would get much encouragement
or support for Sanchez for this but I might be wrong. Sanchez is trying to
bridge a fine line between running open-source and still making a profit and
this is the way that they have chosen to do it. I guess that someone could
remove the arch-dependent sections of GT.M and start porting it over, but
that would be a large job and not one that I would attempt.
VistA is ANSI M compliant and will run on any ANSI M complier, but in recent
times, many of those vendors are gone. Some of open-source M projects might
be capable of running VistA someday, but the only industrial-strength M
system that is open-source is GT.M. I know that there was some work on a
mod_perl that could translate M code to perl to execute it but I think that
you would see a performance hit.
My biggest fear about packaging GT.M is deciding where to install all of the
components at. Presently, it is a tarball and you just dump it where ever.
If we are serious about trying to package GT.M then deciding where
everything needs to go is going to be important and I am not certain that I
have a good handle on that.
-----Original Message-----
From: Andreas Tille [mailto:tillea@rki.de]
Sent: Thursday, August 01, 2002 2:16 AM
When building a Debian package of a bigger software project you have to keep
some simple things in mind: Debian comes on 11 hardware architectures -
possibly more for the next release. That means having one single package
of a huge software has to be builded 11 times. This sucks in terms of
wasting bandwidth and disk space of mirrors etc. The solution is:
Split architecture independend parts from the Debian package in a
separate
gt-m-common_<version>_all.deb (which has /usr/share/gt-m stuff)
which is common for all architectures. In most cases an additional
gt-m-doc_<version>_all.deb (which contains html, pdf, etc.)
makes sense because there might be people who do not want documentation on
*all* boxes running gt-m. The remaining binaries stick to
gt-m_<version>_<architecture>.deb
or can be slitted up into separate runtime and development packages - I
just have to look at the software first to decide. Sometimes this changes
after user wishes... You don't need to be afraid about those splittings
and how to do that. There are powerful packaging tools which just require
the files for the single packages to be listed in some files - voila you
are ready.
More detailed discussion is really off topic here and belongs to the
Debian-Med mailing list. (Instructions how to subscribe can be found at
http://www.debian.org/devel/debian-med/ .)
Once GT.M is packaged some people should stress test these packages to make
sure they are stable and would not cause some trouble. This would make
packaging Vista easier. The same package splitting applies to Vista.
Reply to: