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


From: Mathias Behrle
Subject: Re: [Health-dev] [tryton-debian] gnuhealth packaging
Date: Thu, 27 Mar 2014 14:02:16 +0100

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

Hi all,

> 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

For me the targeted audience and intended use of the gnuhealth package is not
really clear. JFTR I want to desist from repeating my statements done on [1][2]
in this thread and would like to point the interested reader there (I don't
know what is the preferred way of discussion of subjects handled in bug
reports? If it should be preferred to have this information duplicated here
please just tell me).

 
> >> 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.

Exactly. Just init the modules you need. That's also what the client does
behind the scenes.
 
> 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.

Answered there.



[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707632
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707639

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

Attachment: signature.asc
Description: PGP signature


reply via email to

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