Re: Upload GNU Health 2.0 to experimental

2013/9/16 Mathias Behrle <mathiasb@m9s.biz>

* Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Sun, 15 Sep 2013
23:32:14 +0200):

> So what happens here is:
> gnuhealth-server depends on tryton-server
> tryton-server recommends on postgres
>
> When installing the gnuhealth-server and all its dependencies, the packages
> get configured in this order:
> tryton-server
> gnuhealth-server
> postgres
>
> Since gnuhealth-server is using dbconfig-common to configure the database,
> it needs postgres configured and running. On my development box, that was
> the case (since dpkg -i doesn't pull in the dependencies, I had always
> installed those manually beforehand). But when installing on a system that
> doesn't have postgres installed, the incorrect order results in gnuhealth
> not being configured properly.
>
> I had wrongly assume that tryton-server would depend on postgres. But since
> that package requires manual configuration from it's user, they're actually
> fine with only suggesting it (when installing with apt-get/aptitude, by
> default the dependencies are pulled in), so for most users of the
> tryton-server package, suggesting has virtually the same end effect as
> depending:

As you say above: postgresql is in Recommends, not in Suggests. tryton-server
is multi-database capable with a strong preference for postgresql. So Recommends
is the correct place for postgresl /nad will be pulled in default
installations).

It is great that Tryton is multi-database capable, and that's what the Debian package should provide. Why not depend on (for instance) "postgres | mysql | <any other database that is supported >"?

Maybe the question is how to support a user that wants to have it's database on another server. Is there some kind of dummy "server not located on this machine" package?

> postgres will be configured on the system before the user hand-edits the
> configuration files.

I did not have yet a look at the current package, but I see some potential
conflicts here. I think you should never interfere with the package
configuration on the system, be it from the package installation, be it by the
sysadmin. As a solution I would propose to create a completely separate
postgresql cluster for gnuhealth, for which you are free to configure
everything like you want (thus avoiding problems with systems running
postgresql before and besides gnuhealth).

I completely agree, a package should never interfere with the configuration of another package (and we're not doing that in any way). The GNU Health package is using the default configuration of Postgres on Debian, and is also not changing anything to the configuration of the Tryton server.

I think what is needed is to take a step back: what is the goal of packaging a piece of software in Debian?

The original version of the GNU Health package did nothing more than placing the code on the system, and left the user to take care of the configuration (database, etc.). In fact, pretty similar to what the Tryton package does (printing a bit blob of text telling the user to look at the documentation to set up the system). As discussed with Andreas [0], that is not helpful for the user (not very much more than if the user had downloaded a tarball and extracted it to his system).

Although Debian might have a reputation of not being the most user friendly, we nonetheless strive to make the user's life as easy as possible, and provide packages that (as much as possible) work out of the box after an `apt-get install`.

And that's what is happening with GNU Health: it installs the code, but also sets up a database and initializes the database so that a user gets a working system after installing. If the user wants, he can still opt-out of dbconfig-common's setup and skip all that to manually configure his system. A user that would have a specific requirement can still manually edit the config file, we're by no means preventing that: Freedom included!

So to summarize, this is the goal of the GNU Health package in Debian (let's discuss this if anybody disagree):

* Provide a working installation of GNU Health, out-of-the-box. A user should just have to type `apt-get install gnuhealth` to have a working GNU Health installation (both client and server) on his local machine, where the client would automatically find the server installed on the same machine. Unless the user wants it, no manual editing of configuration files should be needed.

* Allow for modular installation:
- Install client-only on workstations (apt-get install gnuhealth-client)
- Install server-only on servers (apt-get install gnuhealth-server)

I'm eager to hear your comments/suggestions/critique!

+Emilien
[0] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2012-November/017921.html