Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On 01/24/2012 07:30 PM, Karsten Hilbert wrote:
On Tue, Jan 24, 2012 at 06:49:03PM -0500, Bhaskar, K.S wrote:
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.
[KSB] Some of us vegetarians would prefer to hold the beef and have tofu
But jokes aside, let's stay with the comparison of a VistA environment
being like a Linux server because the analogy is good.
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
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
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 :-)
[KSB] Let's work with the analogy between VistA and Linux.
A VistA Debian package is like a Linux installer ISO image. It's a tool
that will let you create new VistA environments on your computer, just
like the Linux installer ISO image allows you to create new Linux virtual
machines to run on your computer. Each newly created VistA environment
is the same just as every newly created Linux virtual machine is the same
(let's overlook file system UUIDs for now).
Once you start using and customizing each Linux virtual machine, it
starts diverging from others that you created from the same installer.
It's the same with VistA environments.
You can update each virtual machine with aptitude and Debian package
updates. You can update each VistA environment with KIDS packages.
There are rules for configuring your Linux virtual machines so that
package updates go in smoothly. But depending on the type of
customization that you need to do, you may end up with configurations
where most packages go in smoothly but every now and then, you have a
package with a conflict that you need to resolve manually, or where a
package overrides your configuration which you then need to restore after
running aptitude. So, you must run aptitude on each virtual machine
individually: you can't run aptitude on your host and update all your
virtual machines in one fell swoop. Similarly although there are rules
for configuring VistA so that KIDS packages go in smoothly, in practice
there are usually some configuration settings that cause issues with some
KIDS packages, so you can't just drop packages in - you have to test
before applying each package and you have to make plans to deal with each
conflict. Also, just as, if you are a Linux developer, you can use your
Linux virtual machines to develop new packages that you can export to
other Linux systems, from a VistA environment you can create KIDS
packages to export for other VistA environments to load.
In Linux, when someone creates an updated Linux installer you can't just
use it to update your existing Linux environments. Although it is
theoretically possible to reverse engineer the packages from the new
installer and apply them to your existing environments, it's probably
easier just to update the existing environments by applying the package
I hope this helps. If not, please keep asking questions and I will do
what I can to answer them. I am not a VistA expert, but I have absorbed
enough through osmosis that I can give reasonably good approximate
answers, and know where to go to get exact answers when needed.
GT.M - Rock solid. Lightning fast. Secure. No compromises.
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.