[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How Debian Packaging practices could apply to VistA maintenance and distribution

On 01/25/2012 04:52 AM, Andreas Tille wrote:
On Tue, Jan 24, 2012 at 06:49:03PM -0500, Bhaskar, K.S wrote:
A binary Debian package doesn't make sense: the object files will be
Clarification:  All *.deb packages are "binary packages" in terms of
Debian slang.  The contrast are "source packages" which are used to
create the "binary package".  You always install the binary (*.deb)
packages on your machine and nothing else.

However, if we are talking about the *content* of such a binary package
it can perfectly contain either binary files or source files or a mix of
them - whatever is needed.  So if we follow your advise the binary
Debian package will contain VistA source code files to install it at the
places where they will be grabbed by postinst or whatever.

[KSB] Are there packages that are (for example) pure shell scripts so that there is no difference between a source package and a binary package? A VistA Debian package would be like that.

So, from a size point of view, VistA on the server side will be
about the size of a pure-server GNU/Linux distribution.  It is a
character mode application.  Client applications are completely
OK.  No problem with this.

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.

In VistA, the code and database are tightly integrated.  Even sites
that use only part of the functionality of VistA invariably install
all of it, because even if you only want to implement minimal
functionality (e.g., Admission/Discharge/Transfer), it's almost
impossible to pull that apart from everything else.  Once you start
configuring a VistA environment (e.g., by defining locations), it
becomes more integrated.  Once you add patients, that's another
layer of integration.
Hmmm, just to make sure I understood everything correctly let me assume
we want to remove a VistA package at some point in time but keep the
data it created.  Dpkg expects to find all those files it has installed
in certain places to remove them (as it has installed them before).
What will now happen to your data.  Will these hang around in those
directories which previosely were installed by the packages.  While we
can deel with everything somehow this means extra work^Wfun for the

[KSB] You can't properly separate VistA from the data. On another message I posted to this thread a few minutes ago, I made an analogy between a VistA environment and a Linux virtual machine. You can think VistA environmenta just as you can think of virtual machines: although you can delete a VistA environment completely, just as you can delete a virtual machine, you can't keep the data in a VistA environment and delete the VistA, just as you can't easily keep the data in a virtual machine root partition and delete the rest of the virtual machine.

The best way to think of a VistA Debian package is one that creates VistA environments, just as you would if you had a Debian package that created virtual machines.

-- Bhaskar

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.

I hope this is good beginning.

Kind regards and thanks for the clarification


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.

Reply to: