Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment)
Regarding the database discussion:
In case you haven't tried to install the package yourself, you might
have missed this:
*The user gets asked if they want to have the database created and
managed by the Debian package*
If an advanced user has very specific requirements, they can choose
no, and then only the source code is installed. They are completely
free to configure their installation as wanted.
For other users (just testing out, or that needs just one "plain old"
instance of the database [you should probably not have your
production, testing, and backups on the same server anyway]), they can
select yes, and their database gets created, ready to use, and will be
upgraded and backed up automatically by the system (they can naturally
also back it up manually)
2014-03-27 5:05 GMT+01:00 Luis Falcon
> 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
I'll look into that, it's possibly the cause of the piuparts-reported issue.
> 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
I'm wondering, why would you init those 6 modules, and not directly
health_profile? It looks like that is the module any user would need,
regardless of their use of GNU Health.
> 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.
Yep, already using this.
> 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
I understand that. But I also guess that as the developer of the
package, you are much more familiar with making backups on the command
line and the Tryton user interface than a user that would see the
software for the first time.
Again, you can very easily say No to the database creation, and all
the steps you list are available to you.
If you chose yes, we'll create a database called gnuhealth (same as if
you had followed the installation guide), and you're ready to log in.
One less step in the installation process, and one step closer for the
user to actually test your software.
Remember, a first time user is not interested in the installation
process, on which user the server runs under, if the database server
is Postgres or something else. They want to see the software in
action, create a few patients, see how easy it is to order labs, etc.
That's the user that would answer yes and be ready to roll.
> - It's very easy to use the Tryton client to create the instance from
> scratch, including the database and admin user/password
Agreed, it's easy. But if we can do it automatically for you, it's
even more easy.
> - 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 can select No and do that yourself. Or if you have selected Yes,
nothing prevents you from creating new database instances later on.
> - You avoid all those scripts/loops/variables that I put in previous
> paragraphs :)
That's the DUET (Difficult for Us, Easy for Them) part: if the users
so chooses, the Debian package takes care of these steps. And it's
really 2 or 3 commands, it's not like it's rocket science. At least
all your installations are uniform (same system user, same database
name, same way it got created, same backup procedure)
>
> This is of course my opinion, and there might be scenarios where a
> non-interactive installation as just depicted can be very valid.
Yes, new users.
Experience users can select now if they want.
> 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 :)
Another good reason for having the database created manually: we can
run all the upgrade scripts (the --update=all, and the scripts you
provide e.g. version 2.0.0 and 2.4.0 that alter the database). If the
database hasn't been created by the package, we can't take care of
these steps for the user. Then your system is "broken" immediately
after performing an apt-get full-upgrade: you can't use the software
without reading a gzipped TODO file buried somewhere on your system. I
can guarantee you that would bite a hospital one day in the behind, at
which point they'll blame Debian ;)
> 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
Yep, included (that was what Matthias was against in bug #707632 [0])
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707632
2014-03-27 9:44 GMT+01:00 Karsten Hilbert <Karsten.Hilbert@gmx.net>:
> On Thu, Mar 27, 2014 at 01:05:21AM -0300, Luis Falcon wrote:
>
>> What I would take in consideration for to always include in the package,
>> independently of the GNU/Linux distribution are :
> ...
>> - 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)
>
> In other words it is not like "GNU Health" gets
> installed on a machine and any current or future
> account on that machine can be give permissions
> to use GNU Health - they all need to log in as
> "gnuhealth user" ?
No. The gnuhealth user only exists on the server. The Tryton server
runs under the gnuhealth account.
The users (using a client) connect to the server, and use separate
user accounts.
> That would be an important point to know for
> package creators.
>
> If that's NOT the case the package should
> not muck with "user bashrc", "user .gnuhealthrc"
> etc.
Luis, would you care to explain why the GNU Health user bashrc file
and user aliases are needed? Until now I've never felt anything was
missing, but then again I don't spend my day working on GNU Health.
> On Thu, Mar 27, 2014 at 01:05:21AM -0300, Luis Falcon wrote:
> - Start and stop scripts.
The provided scripts are (if I recall correctly) systemd scripts. For
now Debian is not yet using it, so I'm using a traditional systemv
init script.
We will incorporate the upstream scripts once Debian can use it.
> 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.
Yes, system user, database, etc. all created by the package. Only
thing currently missing is the bashrc file and user aliases, I can
include them if needed.
> Hope it helps and let me know your thoughts.
Definitely. Good discussion, I'm glad for the feedback.
+Emilien
Reply to: