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:[EMAIL PROTECTED] 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.
