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

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



Hello Bhaskar,

this is a really helpful explanation. Let me rephrase (and
slightly change) it as to make sure we've understood:

You attest to that VistA is, basically, on big dark BLOB
sitting on the host OS which the host cannot know anything
about ("cannot" in the sense of "it is too hard to teach the
host about the innards of the VistA blob). That may well be
correct. You also attest, that, of course, a VistA package
can drop that BLOB into the system.

I assume the biggest difference between VistA-blob and
host-OS is that VistA never runs on the bare metal while the
host OS does (I'm sure there's one counter-example with some
obscure hardware out there). IOW, VistA "always" *requires*
a host to be present.

Perhaps it is an even better analogy to think of (in this
case) Debian as the host OS running on the bare metal and
VistaA being a VM living and running on top of that ?

For comparison, surely Debian does not know much about a
BSD-VM and sure as hell doesn't try to update software
inside it (let's ignore that BSD *could* run on the bare
metal).

In the following, replace "BSD" for "VistA":

Technically it would surely be *possible* to

- teach Debian about the tools it needs to run
  on behalf of the BSD-VM to update that
- mount the BSD-VM
- run the BSD upgrader inside the BSD-VM

This may not be very *realistic*, however.

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.

So, what can an upgraded VistA package usefully do ? It can

- make sure there's enough resources for the "next version"
- provide external backup scripts
- provide an improved tool to "create VistA environments"
  on my machine
- 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.

> You can update each virtual machine with aptitude and Debian package
> updates.

BSD hosting a Debian machine could well do the following
sequence when a new Debian has been released:

check-available-space
download-packages
mount-debian-vm
send-to-debian "update-yourself-and-here's-your-package-cache"
remove-package-cache

This, of course, requires at least some knowledge on what's
inside the VM blob.

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

But you can run the above sequence on a bunch of VMs.

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.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


Reply to: