Re: Upload GNU Health 2.0 to experimental
Hi,
On Mon, Sep 16, 2013 at 03:44:49PM +0200, Emilien Klein wrote:
> > 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 >"?
I think this will not help in the gnuhealth case because the Dependency
might be fullfilled by mysql which does not help in the gnuhealth case.
So it is correct to make gnuhealth explicitly depend postgresql.
> 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?
Not that I'm aware of (and it would help neither in your case).
> > 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.
... and this is what dbconfig-common is used for. Mathias, perhaps you
might like to have a look into dbconfig-common.
> 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!
I personally like the way to do this. I admit I never went that far for
the gnumed-server package and upstream is happy about this. However, if
I would have more time for this (or if somebody else would like to take
the challenge) this would be a nice optional (ins the sense you said
above) feature.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: