Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Tue, Jan 24, 2012 at 06:49:03PM -0500, Bhaskar, K.S wrote:
> VistA will be distributed as a large number of source program files
> and database extracts, 100% ASCII source code. The Debian package
> will be around 175MB (33MB routines zipped, 141MB database extract
> zipped, less that 1MB miscellaneous zipped, such as shell scripts).
> Routines will be compiled on the local machine by the postinstall
> script. In fact, compiling routines can even be optional because
> GT.M compiles them on demand.
>
> A binary Debian package doesn't make sense: the object files will be
> approximately twice the size of the routines and both routines and
> object files will be need to be in the package anyway - one of the
> features of the M language is a $TEXT() function that allows a
> program to look at its source code at run time, and most M
> applications use $TEXT().
The above certainly helps to get a grip on VistA.
> M source code, especially as written for VistA is information dense.
> Here is a completely random sample:
>
> IEN . ; otherwise, we're in the IEN subscripts & need to process
> .
> . I DIVAL="" S DIDONE=1 Q
> . I DINDEX="B" N DISKIPMN,DIMNEM S DISKIPMN=0 D Q:DISKIPMN
> . . I $D(@DINDEX(DISUB,"ROOT")@(DIVAL))#2 Q:'^(DIVAL)
> . . E Q:'$O(@DINDEX(DISUB,"ROOT")@(DIVAL,""))
> . . I DIFLAGS["M" S DISKIPMN=1 Q
> . . S DIMNEM="" Q
> . I $G(DINDEX(DISUB,"TO")) D Q:DIDONE
> . . Q:$D(DINDEX(DISUB,"IXROOT"))
> . . D BACKPAST^DICLIX1(DIFLAGS,.DINDEX,DISUB,DIVAL,.DIDONE) Q
> . D TRY
> . Q
:-( This is why I never even considered attempting to look
at VistA at the level I would like to look at it (which says
*nothing at all* about the quality of VistA !).
> So, from a size point of view, VistA on the server side will be about
> the size of a pure-server GNU/Linux distribution.
No problem. Want to run a hospital ? Better have the beef.
> The complexity of VistA comes from its vertical integration.
>
> Consider an office suite or a web server. The package is quite
> separate from the content. It's easy to upgrade LibreOffice without
> touching the documents, spreadsheets and presentations created with
> it, or to upgrade Apache without touching the web pages that it
> serves. VistA is not like that.
Many applications (really) using databases are like that,
consider OpenERP, or even GNUmed - you cannot just upgrade
GNUmed (major versions, that is) and NOT upgrade the server
and database part and still access the patient data. Any
given client (major) version requires a certain database
schema version (of course, GNUmed provides scripts to go
from one version to the next). And it's not just the
database layout but rather also in-database functions that
will have changed. Naturally, VistA is way more
sophisticated in that regard but the basic concept seems to
be the same. If not, further explanation will shed more
light on what's needed.
> So, what a VistA Debian package can do is provide the core VistA
> system that can be installed on a computer and from which
> environments can be created on that computer. Existing environments
> cannot be upgraded by installing an updated Debian package. VistA
> has its own package management system (called KIDS) and each
> installed VistA environment on that computer will need to be upgraded
> by applying KIDS packages.
It is helpful to know the above. Nevertheless, an "updated
Debian package" might be a collection of KIDS packages
conveniently bundled together to KIDS-basedly locally
upgrade an existing VistA, no ? Or else it might be a
script *initiating* a KIDS-based upgrade based on a list of
"pre-selected" KIDS packages (rather than *containing* them
KIDS) ?
PostgreSQL / Perl / R / Python / LaTeX / Ruby (?) all have
their own package/extension management. Both selected
Debian-packaged extensions as well as packages installed
from each repo can co-exist.
A KIDS upgrader tweaked to play nice with a Debian system
might exist and be called in postinst from
apt-get upgrade
when there's a new VistA-server available.
It's probably much more complicated than I think but
essentially it's mostly about glue. Lots of it :-)
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Reply to: