Re: Starting packaging VistA (Re: LSM in Geneva)

[Andreas Tille <andreas@an3as.eu>]

On Sun, Jul 08, 2012 at 12:07:38PM -0400, Luis Ibanez wrote:
> > BTw, I tweaked get-orig-source to use xz compression which saves 150MB.
> >
> Nice !

May be, but to my perception not yet sufficient.
 
> > I have no idea about VistA but I somehow have the gut feeling that the
> > plan to put all this into one large package is not the best idea we had.
> > It might be a better idea to have a 1:1 relation between the VistA
> > packages and Debian packages.  Please note that this is actually no
> > suggestion based on knowledge about VistA organisation but as I said
> > rather a gut feeling.  Perhaps it is possible to establish some
> > semi-automatic packaging mechanism (like it is for instance done for R
> > packages).
> >
> This certainly deserves more brainstorming.

Yes.
 
> R packaging and Python packaging (with easy_install)
> are definitely models that we should take a closer look at.

I do not think that Python packaging is that easy as R CRAN archive
(without knowing the details rather CRAN Perl modules could be
comparable).  The point is that it sounds sensible to me to approach
some automatism in the packaging in some way if possible.
 
> > What I also wonder: How did you decided about the versio number VistA
> > 1.0?
> >
> Totally arbitrary !         :-)

That's not a good algorithm.
 
> I needed to put a number in the file, and...
> there is not quite a "version" of VistA itself.
> 
> There are very specific versions of the individual VistA packages,
> based on the number of KIDS patches that have been applied
> to them, but not a version for the whole.

That makes one point more for separating those KIDS into separate
packages.  For the moment we have three points for bundling VistA into a
set of packages where a Debian package might contain one (or more?) KIDS
(or even one KID might be split into more than one binary package if
this makes any sense):

   1. Whole KIDS compilation is insanely large
   2. Whole KIDS colletcion becomes non-maintainable because if I
      understood you correctly these KIDS are not released in sync
      with all others.
   3. Each single KID is featuring a version number (which we could
      take over simply as Debian package version number.
 
> or use the number "2012" as a year ?

Either date as 0.0.YYYYMMDD or much more welcome the according KIDS
number.
 
> Open to suggestions...

Hope this helps

       Andreas.

-- 
http://fam-tille.de