Introduction: Interested in becoming a packager for fis-gtm and vista

[Luis Ibanez]

Dear Fedora Devel,

I'm interested in becoming a packager for:

* fis-gtm:  an open source implementation of the M/MUMPS language/database
* vista:     The EHR of the Department of Veterans Affairs

I have been working recently with the upstream teams of these two projects
while packaging them for the Debian Linux distribution, and would like to build
on top of that packaging experience to bring both fis-gtm and vista into Fedora.

VistA depends on fis-gtm being available. Therefore I'm first preparing the
package for fis-gtm. I anticipate to be able to upload the fis-gtm package
for review soon


    Thanks


          Luis


-----------------------------------------------

More on my background

Development work of ITK
http://public.kitware.com/pub/itk/gitstat/ITK-2011-12-17/authors.html

Blogs at Kitware
http://www.kitware.com/blog/home/user/6

Blogs at OpenSource.com
http://opensource.com/users/luis-ibanez

Role is OSEHRA
the project creating an open source environment for VistA.
http://osehra.org/users/luisibanez

The Open Source Software Practices class that we teach at RPI since 2007
http://www.opensourcesoftwarepractice.org/

Our upcoming presentation about VistA and OSEHRA at OSCON
http://opensource.com/health/12/7/open-source-electronic-health-records-a...
http://www.oscon.com/oscon2012/public/schedule/detail/24129

[Clive Hills]

Coincidentally I was looking at gtm this weekend.
One of the interesting points in re packaging it is that one must bootstrap
gtm from an existing gtm using the providing source.
I'm wondering a bit how that might be affected by the Fedora packaging
guidelines?

I also use Intersystems cache (non free in every sense of course) although
also Mumps based even if broken under F16/F17.
There's also a seeming FOSS mumpsc compiler out there.

Clive
(an old Pick-ie in fact)

[Garrett Holmstrom]

On 2012-07-16 22:50, Clive Hills wrote:
>  Coincidentally I was looking at gtm this weekend.
>  One of the interesting points in re packaging it is that one must
>  bootstrap gtm from an existing gtm using the providing source.
>  I'm wondering a bit how that might be affected by the Fedora packaging
>  guidelines? 
You need to file a FPC ticket to get a one-time exception.

http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions says:

Some software (usually related to compilers or cross-compiler 
environments) cannot be built without the use of a previous toolchain or 
development environment (open source). If you have a package which meets 
this criteria, contact the Fedora Packaging Committee for approval. 
Please note that this exception, if granted, is limited to only the 
initial build of the package. You may bootstrap this build with a 
"bootstrap" pre-built binary, but after this is complete, you must 
immediately increment Release, drop the "bootstrap" pre-built binary, 
and build completely from source. Bootstrapped packages containing 
pre-built "bootstrap" binaries must not be pushed as release packages or 
updates under any circumstances. These packages should contain the 
necessary logic to be built once bootstrapping is completed and the 
prebuilt programs are no longer needed. This can be done like this:

# Set this to 0 after we've bootstrapped
%{!? with_bootstrap: %global bootstrap 1}

[...]

%if 0%{?with_bootstrap}
   # Do stuff involving the prebuilt files
%else
   # The normal build
%endif

[Luis Ibanez]

Clive,

It is great to hear that you are already interested in gtm.

The good news is that during the Debian packaging
we solved the bootstrapping problem. We worked
along with upstream and with Debian developers
to find a suitable solution.

The reason why gtm is needed in order to build gtm, is
that it pre-processes a set of input files, and generates
code from them. The pre-processing being done by a
gtm compiler.

What we did to break the self-dependency, was to include
in the source distribution (with the agreement of upstream)
the sources of the generated files.

In this way, the build process starts from the full collection
of sources (including the generated files) and no initial gtm
compiler is needed anymore.

In addition, to ensure consistency, once we build the gtm
compiler, we do a second round in which we regenerate
those files the traditional way, and do a second build pass.
In this manner we ensure consistency with the build process
that gtm has used so far.

To instrument all this, we also created a CMake configuration
for gtm, and that helped a lot to control all the details of the build.

The reorganized code that we worked on with upstream is
in this github repository (and branch):

https://github.com/luisibanez/fis-gtm/tree/hackathonjune2012-brad

The upstream team will be making a fresh release at some point
with this new collection of files, at:

http://sourceforge.net/projects/fis-gtm/
(not there yet).


If one works from the CMake-ified sources (in the github repository
above), the package can be built by using only gcc through:

    cmake  .
    make -j 4
    make install


There were other modifications details, that we will be
happy to describe further if anyone is interested.


With this fis-gtm package, we were also able to build
the package for VistA. (where fis-gtm is the only
dependency for the vista package).


   Luis