health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception whe


From: Emilien Klein
Subject: Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment)
Date: Wed, 26 Mar 2014 22:08:46 +0100

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.


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]