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

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

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
> > separate.
> 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
> packager.

[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.

Regards
-- 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.
> OK.
>
> > I hope this is good beginning.
> Yes.
>
> Kind regards and thanks for the clarification
>
>         Andreas.

--
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.