Re: VistA packaging : vista-foia : First review
Hi Luis,
thanks you very much for your intensive work on the VistA packaging.
It would definitely not be possible without you.
On Wed, Jan 29, 2014 at 10:14:48PM -0500, Luis Ibanez wrote:
> Good News:
> ----------------
> We have made good progress in the vista-foia package,
> and it seems to be ready for a first review by experienced
> Debian developers.
I'll have an intensive look at your work at the Debian Med sprint - I'm
just on my way to Stonehaven lurking on an Airport WLAN ...
However, my first attempt to call git-buildpackage endet quickly in
...
dpkg-source: info: local changes detected, the modified files are:
vista-foia-0.20140106/CMake/ListOfVistARoutines.cmake
vista-foia-0.20140106/CMake/UseGTM.cmake
vista-foia-0.20140106/CMakeLists.txt
vista-foia-0.20140106/Python/vista/OSEHRAHelper.py
vista-foia-0.20140106/Testing/Setup/CMakeLists.txt
vista-foia-0.20140106/Testing/Setup/ImportRG.cmake.in
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/vista-foia_0.20140106-1.diff.vMQYZY
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -i.git -I.git -b vista-foia-0.20140106 gave error exit status 2
gbp:error: Couldn't run '~/bin/git-pbuilder': ~/bin/git-pbuilder returned 2
> Current State:
> -----------------
> We have configured the generation of the orig.tar.gz file,
> and we succeed to build the content it using "debuild",
> then managed to install the resulting .deb package.
I tested using debuild after I've got the pristine-tar out of the Git
repository. May be you need to apply your changes in quilt patches or
even tweak the upstream tarball creation with the files above? Or am I
fooled by some different usage of the Git repository?
> Particularities:
> ------------------
> This package is build out of the combination of two source trees.
>
>
> a) VistA-M: The actual MUMPS code written by the US Department
> of Veterans Affairs, and now hosted by OSEHRA at:
>
> https://github.com/OSEHRA/VistA-M
>
> This is a rather large source tree with 27,484 files (.m) containing
> MUMPS routines, and 2,933 files (.zwr) containing "globals"
> (Think of globals as akin to JSON files with the structure of the
> VistA database )(MUMPS developers out there, please forgive
> us for the license taken in that comparison... this is all in good
> spririt)
>
> VistA-M is a hefty package, given that it is the result of more
> than forty years of development and use in several hundred
> clinical facilities.
>
>
>
> b) VistA: A scaffolding infrastructure used to configure, build, test,
> and update the VistA-M tree mentioned in (a). This is a smaller
> source tree, and is mostly based on CMake and Python scripts.
>
> A clone of this tree has been put in Alioth, and has been modified
> to add the "debian" directory and a set of patches that facilitate
> the creation of the debian package. We will be merging this with
> upstream, to reduce the future burden of maintenance.
>
>
> The upstream location of this tree is hosted by OSEHRA at:
>
> https://github.com/OSEHRA/VistA
>
>
> The cloned/adapted tree for debian packaging is in Alioth at:
>
> http://anonscm.debian.org/gitweb/?p=debian-med/vista.git
>
>
> with a clone here:
>
> https://github.com/luisibanez/vista-debian-med-package
>
>
>
> The combined build has been configured by placing the source
> tree (a) in a sub-directory of (b) at the moment of doing
>
> "get-orig-source".
>
> This could be simplified by using git sub-modules, and setting
> VistA-M as a git sub-module of VistA. It all depends on what is
> more convenient (and more acceptable) to ftpmaster.
Well, I think ftpmaster accepts the tarball we are providing as
*.orig.tar.gz as long as it contains files with a free license
exclusively. Usually the method to create the tarball is not
questioned by ftpmaster. You have "better" chances to recive
critics by your fellow Debian Med team members if they are not
able to reproduce what you did to create the tarball. ;-)
> Building:
> -----------
>
> When calling "debuild", the packaging happens in four stages:
>
> 1) Creation of a "vista instance skeleton". This is a set of directories
> where we are going to import the MUMPS routines, and to import
> the globals into a database.
>
> 2) Configuration of CMake infrastructure. This is done as part of the
> "configure" script, and it results in a set of Makefiles being
> generated.
>
> 3) Build. In this step the Makefiles invoke a set of CMake and Python
> scripts that take care of:
>
> Importing routines, importing globals, doing basic configuration,
> pre-compiling all the MUMPS routines, and creating a shared library
> with the 27,000+ resulting .o files.
>
> 4) Install. Copying the final "vista instance" into the destination
> directory.
>
>
> debuild, nicely package the whole into the .deb file.
I can not confirm this at my side with an up to date clone of the Git
repository.
> Local Installation Test:
> ----------------------------
> At the end of the build process we get files:
>
> vista-foia-0.20130405_0.20140106-1_amd64.deb
> vista-foia_0.20140106-1_all.deb
Hmmm, this is some unusual versioning scheme. (scroling down to your
explanation below ...)
> that we can locally install with the command
>
> sudo dpkg -i vista-foia-0.20130405_0.20140106-1_amd64.deb
>
>
> and in this way place the "vista instance" in the directory:
>
> /usr/share/vista-foia/V-0.20130405
Looks reasonable so far (without having the chance to look at the
according *.deb ...
> Version Numbering Scheme:
> ------------------------------------
>
> Because the package combines the two source trees mentioned
> above, there are two names and versions that are relevant to the
> package.
>
> For the source tree of VistA-M, which is the actual MUMPS code
> of VistA, we are using the date of the most recent FOIA release
> that has been fully processed by OSEHRA. This is from the date
>
> April 5th 2013
>
> Hence the package is being named:
>
> vista-foia V-0.20130405
OK, makes sense.
> The scaffolding (CMake + Python), on the other hand, that was
> branched from the VistA repository in OSEHRA, is based on the
> version of date:
>
> January 6th 2014
>
> Hence its version is marked as:
>
> 0.20140106
>
> In this way, we are attempting to differentiate the version of the
> VistA MUMPS project, from the version of the VistA CMake
> infrastructure that is used to build the former, and subsequently
> to package it for Debian.
This sounds a bit unusual to me. Without beeing able to estimate the
amount of code in the scaffolding (CMake + Python) stuff I would suggest
to stick to one single version. My idea is that if we might have
finalised this step you should have one single packaging for
V-0.20130405. May be we might need some letter encoded upgrade path
like V-0.20130405[abcde] or so - but my gut feeling says that the
complex versioning is something we want to avoid.
> Intended Use:
> ------------------
> We anticipate that the Debian user of this package will follow
> a bit the model of how a MediaWiki is installed and deployed,
> or how a Moodle system is installed and deployed. That is,
> there is the "installation" of the package code and configuration
> files, then there is the "deployment of an instance", of which
> one can have many in the same Debian machine.
Sounds reasonable.
> For the first part, we get it done with:
>
> sudo apt-get install vista-foia
>
>
> For the second part,
> a Linux user with sudo access will run the script:
>
> /usr/share/vista-foia/V-0.20130405/deploy/createVistaInstance.sh
>
> Thanks to Chris Edwards (from KRM) for crafting this script.
>
>
> The use will be along the lines of
>
> sudo ./createVistaInstance.sh inst001
>
> where "inst001" will be our made-up name an installation.
>
>
> Base on this name, a set of dedicated three Linux users will be
> created in the system, and then, in the home directory of one
> of them, the script installs a fresh "vista instance", by mostly
> copying some pieces from the pristine template that is in:
>
> /usr/share/vista-foia/V-0.20130405/
>
> The MUMPS routines, and their compiled objects (an .so file)
> will remain in the pristine directory in /usr/share/vista-foia...
>
> The fresh "vista instance" can then be configured as a clinical
> facility, and data can now be entered into it to make it usable
> for EHR teaching and training. Permissions and security are
> managed by taking advantage of the users permissions given
> by the Linux account system.
>
> Presumably, a professor teaching an EHR class, will do such
> fresh installations for every student in the class, and in that
> way, each one of them will be able to enter data, and tinker
> with her/his own system without impacting others.
>
> Something like
>
> sudo ./createVistaInstance.sh inst001
> sudo ./createVistaInstance.sh inst002
> ..
> sudo ./createVistaInstance.sh inst031
>
>
> The fresh vista instances will be mostly their own MUMPS
> database, while they all will be sharing the MUMPS routines
> installed in the pristine directory:
>
> /usr/share/vista-foia/V-0.20130405/
>
> in the shared library:
>
> /usr/share/vista-foia/V-0.20130405/lib/libvista-foia.so
>
>
> Student will still be able to play with modified MUMPS code,
> by taking advantage of the mechanism that fis-gtm uses to
> locate routines, which is based on a path (set of directories)
> in the environment variable "gtmroutines". Students will
> simply need to add their local directories at the beginning
> of the list in the gtmroutines environment variable, and leave
> towards the end the locations of the directories in the pristine
> installation. More specifically:
>
> /usr/share/vista-foia/V-0.20130405/r
> /usr/share/vista-foia/V-0.20130405/lib/libvista-foia.so
It is hard to me to comment on this but it basically is what I
understand about VistA from previous discussion. I guess it is
Bhaskar's task to comment this. :-)
> Review:
> ----------
> Since this is the first cut at a vista-foia package we are
> sure that there are many parts that need fixing, to comply
> with Debian policy, and many pieces that could be done
> more efficiently and probably more elegantly.
>
> We will appreciate all the guidance and advice that you
> could provide us, and will be happy to adjust the package
> as needed.
I think it would help if it would be buildable straight from the Git
repository (see above). If you can not verify my observation just let
me know and I need to have a closer look into this.
> Many Thanks
Thanks to you as well
Andreas.
--
http://fam-tille.de
Reply to: