On Sat, Jul 14, 2012 at 12:10 PM, Andreas Tille <[email protected]> wrote:
>
> I confirm that the questions Nicolas Barbier has asked in his replay to
> your mail are the same questions which are somehow bothering me as well
> (so I will not repeat these here).
>
> > /var/lib/vista/
> > /var/lib/vista/r
> > /var/lib/vista/o
> > /var/lib/vista/g
> > /var/lib/vista/j
> > /var/lib/vista/logs
> > /var/lib/vista/inetd
> > /var/lib/vista/profile
> >
> >
> > The directories "j" and "logs" were added during the Code Convergence
> > conference call last Thursday, to accommodate for Journaling and Logs.
>
> There is no precedence for storing Journals as far as I know
Ok, I'll ignore the Journaling by now,...
Maybe Bhaskar can advise on what is
the right thing to do with that directory.
> but
> regarding the logs, I'd definitely move these to
>
> /var/log/vista
>
>
Ok,
I just did this.
We now have
/var/log/vista
/var/log/vista/inet
> and this could be "hidden" from the VistA code by a simple
>
> ln -s ../../log/vista /var/lib/vista/logs
>
>
Since all these directories are pointed to by environment variables,
we don't quite have to put them under /var/lib/vista, and therefore,
I'm placing them directly where Debian policies will guide us to put
them. So,... the good news is that we won't need the symbolic links.
We just need to make sure that we set the environment variables
to point to the new locations of these directories.
> to fake your suggested directory layout (which is OK in principle).
>
> > The inetd directory hosts two files with configuration for CPRS / xinetd.
>
> Uhhmmm, please don't put configuration outside /etc! Also here the
> solution will be something like
>
> /etc/vista/inetd
> ln -s /etc/vista/inetd /var/lib/vista/
>
> or something like this.
>
>
Ok,
The configuration file is now going to:
/etc/xinetd.d
the full path is :
/etc/xinetd.d/cprs_vista_xinetd
The other file is the shell script that plays the role of a callback when
a user of CPRS (the GUI client) talks to the port (9430 in this case).
That shell script triggers a VistA routine via gtm commands.
This shell script is now in
/var/lib/vista/inet
and it is called:
/var/lib/vista/inet/cprs_vista_rpcbroker.sh
it probably should be associated with the user rather than being in
a system wide location. Particularly because it sets the environment
variables that, as Bhaskar pointed out in on of his recent emails,
define the tree-like environment.
(I'll revisit this...)
> The profile directory host an example profile file, that a user could copy
> > to set up the environment with the proper environment variables pointing
> > to the VistA instance.
>
> Examples should rather go to
>
> /usr/share/doc/vista
>
>
Ok,
I just did this with auto_install...
We now have:
/usr/share/doc/vista/vista_profile
> and you can use dh_installexamples to do so.
and now I'm reading on how to do it with dh_installexamples,
that definitely looks cleaner.
> Please use the file
> debian/README.Debian to explain what the user is supposed to do with the
> examples.
>
>
Yes,
I added some instructions to README.Debian,
along the lines of "what to do just after you installed the vista package".
It makes me think that we should add more of a 101 Tutorial
in the directory:
/usr/share/doc/vista
Something like
/usr/share/doc/vista/GettingStartedWithVistA.txt
intended for full beginners that are prospective developers.
I'll see what I can put together....
> If I'm following correctly, it seems that we should have in this path the
> > version name/number of the fis-gtm that was used to create the instance.
> >
> > Maybe something like:
> >
> > /var/lib/vista/V5.5-000_x86_64
> > /var/lib/vista/V5.5-000_x86_64/r
> > /var/lib/vista/V5.5-000_x86_64/o
> > /var/lib/vista/V5.5-000_x86_64/g
> > /var/lib/vista/V5.5-000_x86_64/j
> > /var/lib/vista/V5.5-000_x86_64/logs
> > /var/lib/vista/V5.5-000_x86_64/inetd
> > /var/lib/vista/V5.5-000_x86_64/profile
> >
> >
> > Would this make sense ?
>
> Yes as far as it regards the version number. I do not really see the
> need of specifying the architecture here and would rather drop this.
> What I wrote above with the unversioned dir should be easily applicable
> to the versioned dir.
>
>
Sounds reasonable, and easy to do.
I'll take a crack at this directory renaming,
as soon as I get CPRS to work with the
installed package.
Thanks
Luis
