[Debian-med-packaging] Bug#707632: Bug#707632: gnuhealth: Package layout

[Mathias Behrle]

* Emilien Klein: " Re: [Debian-med-packaging] Bug#707632: gnuhealth: Package
  layout" (Wed, 26 Mar 2014 21:59:01 +0100):

Hi Emilien,

> Matthias, we had discussed this in the past, but I hadn't taken the
> time to properly respond directly on the bug report.
> 
> Your (welcome!) contributions on the recent discussion [0] finally
> forces me to take care of this topic ;)
> 
> Regarding your suggestions to split the gnuhealth Debian package into
> one binary package for each modules, I still object to that. I see
> absolutely no benefit to the user to have him perform the following
> workflow:
> 
> - Install a barebones gnuhealth-server package using APT
> - Launching the Tryton client, initializing the base GNU Health module
> (health_profile)
> - Testing around, determining it's missing the functionality provided
> by the health_blabla module
> - Close the client, go back to the terminal/software center
> - Install the gnuhealth-blabla module using APT
> - Restarting the Tryton client and having to select the blabla module
> to initialize it
> 
> A workflow like this is thus much easier for the user:
> 
> - Install a the gnuhealth-server package using APT
> - Launching the Tryton client, initializing the base GNU Health module
> (health_profile)
> - Testing around, determining it's missing the functionality provided
> by the health_blabla module
> - Stay in the Tryton client, select the blabla module to initialize it
> 
> The total size of all the GNU Health modules once installed is less
> than 45 Mb. Disc size is thus not an issue.
> 
> The modularity that makes Tryton great lies in the ability to select
> which modules you want to use. You can have modules installed that you
> don't use, so there is no problem in installing all the GNU Health
> modules in one package.
> 
> This also alleviates the issues that you are facing, whenever a new
> Tryton module is released, you need to have it uploaded by a Debian
> Developer, and the package has to be processed in the NEW queue, etc.
> 
> Please let me know if you strongly disagree, if so please give
> technical details on why the package should not provide all modules.
> If not, I will soon close this issue.

Thanks for your feedback. I will try to rephrase my concerns about the current
package layout.

1) All modules in one binary package

You know best yourself, that you had to some work to exclude a module in the
first place from being packaged (because of missing dependencies IIRC). Another
really strong argument is the KISS principle Tryton is following. Building
sensible applications (be it for businesses or for hospitals, they all manage
sensible data) takes care to really only install the software you need for the
task. Each piece of software introduces a point of failure. Thus the modularity
of Tryon is not just made for fun, but has a strong reason. This principle is
broken with the single gnuhealth upstream tarball used for the current Debian
packaging. BTW the tryton-modules-all package is just meant as a tool for
testing, pulling quickly in dependencies, getting a first impression. It is for
sure not recommended for production use.

I am not in the position to evaluate, if the modules currently included in the
gnuhealth package will be used by each gnuhealth user *anyway* (because the
package otherwise is useless). 

It is completely up to you to decide, if a minimal installation really needs
all modules. Otherwise it is not best practice with respect to data security.

2) Package layout and targeted audience

I am still missing a clear concept, for which audience the gnuhealth package is
targeted. With the arguments from 1) the package in its current shape for me is
a demo package. 
Doing automatic backups and upgrades is a very responsible job. I personally
never would dare to give the impression, that the package can provide an
application that can be used without some basic knowledge of its
administration. Remember, that we are always in contact with sensible data and
sensible setups. A hospital using its system will strongly depend on its
functionality. Upgrades should be done anyway by some knowledgeable person.
This person should also take care of the upgrade of such an application, at the
time he/she wants and with the full knowledge how to return to a previous
working state.

I don't think, that the current layout of the gnuhealth package is fit
for the use in sensible environments. 

Just my 2¢.


Cheers,
Mathias


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20140327/422f90c6/attachment.sig>