Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment)

[Luis Falcon]

Hi Emilien, Mathias !

On Wed, 26 Mar 2014 22:08:46 +0100
Emilien Klein <address@hidden> wrote:

> Thanks all for looking into the issue.
> 
> 2014-03-26 16:30 GMT+01:00 Mathias Behrle <address@hidden>:
> > * Luis Falcon: " Re: [tryton-debian] [Health-dev] [tryton] Re:
> > Exception when building the package in a cleanroom Debian
> > environment" (Wed, 26 Mar 2014 10:33:35 -0300):
> >
> > Hi Luis, hi all,
> >
> >> On Tue, 25 Mar 2014 19:10:00 +0100
> >> Mathias Behrle <address@hidden> wrote:
> >>
> >> > * Luis Falcon: " [tryton] Re: [Health-dev] Exception when
> >> > building the package in a cleanroom Debian environment" (Mon, 24
> >> > Mar 2014 19:02:30 -0300):
> >> >
> >> > Hi Emilien, hi all,
> [snip]
> >> > I can not provide actually a fix withotu digging further into the
> >> > gnuhealth package, but just some hints:
> >> >
> >> > 1) tryton-server [1] is passing piuparts and basically this seems
> >> > also to apply for gnuhealth-server [2]. The error seems to be
> >> > caused by the gnuhealth package scripts or the tools it uses.
> >> >
> >> Thanks for the info.
> >>
> >> I am looking now at the the database-scripts/install/psql script
> >> of the Debian package.
> >>
> >> It's not a good idea to init all the modules. In fact, I wouldn't
> >> create any database . The DB creation, modules selection depends
> >> on the needs of each user or Health Institution. In fact some of
> >> them - like health_ICD10-PCS and health_ICPM should be mutually
> >> exclusive.
> >
> > I guessed something like that without deeper knowledge of
> > gnuhealth, thanks for confirming. Quite a while ago I had a look at
> > the gnuhealth package and shared my opinion in proposing a
> > different package layout [1][2]. The gnuhealth package is
> > maintained by the Debian Med Packaging Team
> > <address@hidden> and I think they
> > will be glad to receive feedback.
> 
> We appreciate the feedback Matthias, we discussed this topic in the
> past. See below for a bit more details.
> 
> >> If you want to have a demo GNU Health instance  with a set of
> >> modules, functionality, then we can provide you a postgres dump
> >> for that version. That's what Axel is working on with the LiveCD
> >> demo for OpenSUSE.
> >
> > While a postgres dump could be a solution to create a basic setup,
> > I even would prefer to use a proteus script, like the one used to
> > create the demo database on demo.tryton.org. This would make
> > independent from the postgres version, being more flexible, being
> > better maintainable, etc., since it just uses an existent and
> > working Tryton server setup.
> 
> The goal is not to provide a demo system (that will be done with a new
> binary package gnuhealth-demo, which will create it's demo database
> using the script provided by upstream for that purpose). The database
> is created to allow the user to directly log in, after having
> installed the package.
> There is nothing dependent on e.g. the Postgres version in executing
> 
> >> If the Debian package installs the server and modules;
> >> configuration files; gnuhealth OS and DB user and environment
> >> variables would be more than enough.
> >>
> >>
> >> Just as curiosity, can you check the DB encoding of the created DB
> >> (psql -l will show it).
> >>
> >> Again, we should not create the DB as part of the installation
> >> process though.
> >
> > I don't see see the point in not creating an initial database (with
> > respect to the goal of an one-in-all package). I agree on not
> > installing the whole module set by default into the database. As
> > previously said I would split the gnuhealth package into more
> > manageable packages.
> 
> Indeed.
> The benefits of having the Debian package create the database at
> installation are multiple:
> - one less manual action that every user would have had to perform
> anyway once
> - allows to include making backups as part of upgrades
> - allow applying the upgrade patches submitted by upstream
> automatically
> 
> For more details, read the [short] section "Overview of package
> installation/upgrade/removal processes" from the Best practices for
> database applications document [0].
> 
> My goal is not to initialize all the modules. It is to:
> - install all GNU Health modules on the hard drive
> - create the database so that the user can just launch the client and
> type it's admin username/password
> - just have the user select which modules they want to use.
> 
> The user should be able to jump directly to step 4 "Logging into the
> application" [1] of the GNU Health installation steps, possibly
> without having to perform step 5 "Installing the default modules", but
> still the ability to do step 6 "Installing Extra Modules" if they want
> to.
> 
> I'd be interested in knowing if there is a way to create the Postgres
> database, make it recognizable by Tryton, but without having to init
> all modules (basically step 3.3 "Creating the GNU Health database"
> [2]).
> Any thoughts on how to perform that?
> Writing about it, maybe executing "trytond --init=health_profile"
> instead of "trytond --init=all" is what I'm looking for? Please let me
> know.

ok, let me first describe a technical solution to your question, and at
the end, what I would approach to the package (conceptual, valid for all
GNU/Linux distros ;-) ).

This is some steps you could take to init a GNU Health instance called
"gnuhealth"

1) Create the DB with the UTF8 encoding. I believe that the DB encoding
might have been the cause of the encoding error you encounter at first.

$ createdb gnuhealth --encoding=unicode

2) Init the Tryton instance and the core health module with its
dependencies (country, party, currency, company and product). This
little BASH loop would do the job.

$ for health_core_mods in ir country party currency company product
health; do ./trytond --init=${health_core_mods} --database=gnuhealth;
done

The server will ask you for the admin passwd at the terminal
window after installig the "ir" module. If you don't want to enter the
admin password at the termina, you can put the passwd on a temp file and
refer to it with the TRYTONPASSFILE environment variable before
executing the for loop. 

3) Start the Tryton server
$ ./trytond

4) Start the Tryton client, you will be presented with the wizards to
create the users and company (the health institution). From there, you
can pick other modules or just work on the core GNU Health
functionality.

You should be done.

NOW... that said, I prefer *not* creating a db instance as part
of the package installation process, because

- It's very easy to use the Tryton client to create the instance from
  scratch, including the database and admin user/password
- You can choose your own DB name for each instance, for the sandbox,
  development, test and production instances you would need to specify
  different DB names
- You avoid all those scripts/loops/variables that I put in previous
  paragraphs :)

This is of course my opinion, and there might be scenarios where a
non-interactive installation as just depicted can be very valid. 

In the case of upgrades, we send the instructions as per release (normally
just --update=all ). But you if the maintainer includes it on the
package, fantastic :)

What I would take in consideration for to always include in the package,
independently of the GNU/Linux distribution are :

- All the modules included on each release's tar.gz file
- Create the gnuhealth user at OS level and give the appropiate DB
  permissions.
- GNU Health user bashrc file
- GNU Health user aliases, matching the directory and file locations of
  the specific distro (cdexe, editconf, cdlogs, cdconf... ). They are in
  the $HOME/.gnuhealthrc file when using the standard/generic installer
  (gnuhealth_install.sh)
- Start and stop scripts.

This is important, so, independently from the distro used, the user
will find the GNU HEalth book easy to follow (or at least that's our
goal :) ). They are also very handy to make go to the right place and
edit the right file.

Hope it helps and let me know your thoughts. 

Best,
> 
> 
> Matthias, regarding your suggestions to split the gnuhealth Debian
> package into one binary package for each modules, I still object to
> that as I see
> absolutely no benefit to the user.
> I have responded more in detail directly in bug#707632.
> 
>     +Emilien
> [0]
> http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbapp-policy.html
> [1]
> http://en.wikibooks.org/wiki/GNU_Health/Installation#Logging_into_the_application
> [2]
> http://en.wikibooks.org/wiki/GNU_Health/Installation#Creating_the_GNU_Health_database
> 
> 



-- 
Luis Falcon
GNU Health : The Free Health and Hospital Information System
http://health.gnu.org
@gnuhealth