Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 11:50:41AM -0500, Bhaskar, K.S wrote:
> >Another approach would be to drop package management from
> >BSD and make it rely on the host OS package management.
> >Possible but not feasible, I fully agree.
> [KSB] Let's take the analogy between VistA and a hosted virtual
> machine a bit further. Suppose the virtual machine's root file
> system was booted off a partition on the host using a copy-on-write
> virtual disk, or NFS mounted, or via an iSCSI target. In that case,
> it is possible to update virtual machines by making changes at the
> host. But you cannot make all changes at the host - some changes
> will need to be made within the virtual machines, and you have to
> know what you are doing. Similarly, VistA is not an opaque blob.
> You can make some changes at the host, but others will need to be
> made within VistA, and it requires expertise to know what is correct.
This confirms my current understanding of VistA. Good.
> >So, what can an upgraded VistA package usefully do ? It can
> >
> >- make sure there's enough resources for the "next version"
> [KSB] I am not sure if this relevant. There are always enough
> resources, since the limits are the host filesystem and database.
Exactly. It can make sure that the host filesystem and
database and RAM and CPU provide sufficient resources to
still run VistA after applying an upgrade.
In the most basic sense it can check whether there's enough
disk space for:
- downloading recommended new/updated KIDS packages
- unpacking them
- installing them
> >- provide external backup scripts
> [KSB] This is easily done with simple shell scripts.
Exactly. And those can be provided by (and delivered in
improved form) the (regularly updated) Debian package.
> >- serve as a reminder to less-inside VistA people telling
> > us "VistA insider Bhaskar decided that now there's a
> > useful/important/needed collection of KIDS packages
> > available which you really should install"
> >- helpfully download those KIDS packages into a local cache
> > while I'm still busy doing something else
> >- tell the VistA-blob/-VM on our machines the following:
> >
> > /usr/sbin/hey-vista-upgrade-yourself --from=here
> >
> > which could then run interactively and require my
> > intervention as needed
> >
> >That would seem to me a useful level of integration already.
> >
> >But maybe this is a pipe dream for one reason or another.
> [KSB] VistA already has infrastructure to send KIDS packages to
> registered recipients via e-mail.
So much the better. The Debian-resident VistA guru would
receive said email, review packages by "naive" Debian users
and "approve" them for inclusion in/recommendation by the
next VistA package. This will
- provide for Debian-smoothed installation of "approved" KIDS packages
- tell Debian VistA users about "new" packages in a way they
are used to
> >A Debian package need not "take away" from what VistA
> >already does or re-create functionality VistA already has.
> >But it can provide glue and Debian-like access to VistA
> >functionality.
> [KSB] Agreed. We should let VistA do what it does and supplement it
> where appropriate.
That approach is IMO reasonable.
> In my experience, the mechanics of installing VistA are
> straightforward. Configuring VistA is a major project because it is
> a complete ERP system for a hospital (it even has features for
> managing inventory, for example). Over the years, one source of
> disappointments that I have seen when people install VistA is the
> realization that while installing VistA can be done in minutes,
> getting it running even for a small practice takes expertise.
That much I knew.
That would be another possible source of Debian VistA packages:
- vista-single-practice-template.deb
- vista-multi-practice-template.deb
- vista-hospital-basics.deb
- vista-hospital-surgery.deb
- vista-hospital-internal_med.deb
...
Of course, even after installing *that* a lot of
configuration will still need doing. But maybe such
templates are already available inside VistA.
Or perhaps the above should simply be scripts installed by
vista.deb doing/invoking the appropriate VistA action.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Reply to: