* Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Mon, 16 Sep 2013
15:44:49 +0200):
> 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 >"?
Because Tryton also works with sqlite and sqlite is in Python. This is also the
default database used for testing and with neso. You don't want to install some
full fledged database when only using neso. With respect to neso, postgresql in
Recommends is already too much...
> 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?
That's exactly the generic layout of tryton-server. It is out of scope of the
base packages to provide installation routines for each and every special use
case.
> > > 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).
This "blob of text" ;) is due to replacement.
> 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`.
I agree with 'as much as possible', which also means: keep all the possibilities
of running Tryton as cluster against a database cluster and nevertheless to not
install software that is basically not needed for individual use cases.
If you want to package gnuhealth as a standalone package for one machine and
to get users fast into touch with the software, the current layout may fit. It
won't fit very well for installations running the Tryton server(s) on (a)
different machine(s) than the database server(s). I pointed this already out in
[1].
> 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!
The user has no more the "freedom" to install gnuhealth without postgresql.
> 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)
The two lines above are contradictory with "`apt-get install gnuhealth` to have
... (both client and server) ". I don't see any benefit in installing the gtk
client including all dependencies onto a pure server machine. Again hinting to
[1].
Speaking of "modular installation" also doesn't keep in mind modularity with
respect to gnuhealth modules. There are good chances that gnuhealth users
currently want to have installed all related modules and you are save to
eventually split out individual module packages later. So I don't see any
problem for now when packaging the gnuhealth modules in a bunch. Nevertheless
for me the current concept of gnuhealth is rather monolithic than modular...
> [0]
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2012-November/017921.html
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707632
Cheers,
Mathias
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Attachment:
signature.asc
Description: PGP signature