Debian Bug report logs - #707632
gnuhealth: Package layout

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: submit@bugs.debian.org

Subject: gnuhealth: Package layout

Date: Thu, 9 May 2013 21:54:30 +0200

[Message part 1 (text/plain, inline)]

X-Debbugs-CC: <tryton-debian@lists.virtual-things.org>
Package: gnuhealth
Version: 1.8.1-1 (svn rev 13528)
Severity: wishlist

General layout of the package:

Please consider to package the health modules individually.

   Packaging all modules in one package breaks the modularity of Tryton. This
   way it will be impossible to reuse single modules. As already stated in a
   recent mail, this is a problem when using the relase tarball from gnu.org
   [2]. As pointed out, it is alternatelively possible to package from the
   releases on pypi.org. This would provide separate modules and keep the
   modularity, which is one of the major features of the Tryton framework.
   NB: Besides a clean modular structure it would have saved the hacks in the
   rules file in override_dh_auto_install (removing health_qrcode etc.).

   My concept would have been:
   * Separate packages of the health modules in the namespace
     tryton-modules-health-* (as done generally for Tryton modules so far).
   * One package for all modules as done for tryton-modules-all
     - tryton-modules-all-health (superseeding health_profile the Debian way).
   * Additional packages containing the customized configuration like
     - tryton-server-gnuhealth
     - tryton-gnuhealth-allinone

   Apart from this I would talk (and talked already;) to GNU Health upstream, if
   they don't see advantages in handling their repositories like Tryton
   upstream. The current state is somewhat in between real modularity and a
   single module.


-- 

    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

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 707632@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien+debian@klein.st>

To: 707632@bugs.debian.org

Cc: Mathias Behrle <mathiasb@m9s.biz>

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

Date: Wed, 26 Mar 2014 21:59:01 +0100

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 time maintaining the Tryton modules, and reviewing the
GNU Health package
   +Emilien

[0] https://lists.debian.org/debian-med/2014/03/msg00202.html

Message #15 received at 707632@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Emilien Klein <emilien+debian@klein.st>

Cc: 707632@bugs.debian.org

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

Date: Thu, 27 Mar 2014 13:27:19 +0100

[Message part 1 (text/plain, inline)]

* 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

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 707632-done@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien@klein.st>

To: 707632-done@bugs.debian.org

Subject: Closing bug report

Date: Sun, 29 Jun 2014 08:59:29 +0200

As GNU Health was removed from the archive, this bug report is "fixed".
Closing bug report.

Mathias, I am confident that in case you are picking up the package
[0] you will make sure to address your concerns ;)

Thanks for your help and comments on this package.
   +Emilien
[0] http://lists.gnu.org/archive/html/health/2014-06/msg00008.html

Message #25 received at 707632@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Emilien Klein <emilien+debian@klein.st>

Cc: Debian Med Project List <debian-med@lists.debian.org>, Tryton package maintenance in Debian <tryton-debian@lists.debian.org>, 707632@bugs.debian.org

Subject: Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)

Date: Sun, 29 Jun 2014 16:49:27 +0200

[Message part 1 (text/plain, inline)]

* Emilien Klein: " Force removal of gnuhealth* packages in sid? (Was: Re: GNU
  Health autoremove from testing)" (Sun, 29 Jun 2014 09:09:30 +0200):

Hi Emilien,

> 2014-06-10 14:46 GMT+02:00 Emilien Klein <emilien+debian@klein.st>:
> >> > The packages gnuhealth-server and gnuhealth-client will have to be
> >> > removed from sid (and from testing once the new package migrates to
> >> > testing).
> >>
> >> The removal of the binary packages is automatically done once the
> >> package with the changed binary package names will be uploaded.
> >
> > I guess we can just wait for the autoremoval period to lapse, and the
> > package will be removed automatically.
> 
> Since there will be no upload of the newest version of the source
> package (newer Tryton version preventing building of GNU Health
> 2.4.X), the change in binary names will not be observed by the release
> system. I suppose I have to take manual action to remove that package
> from sid as well (the gnuhealth* packages were autoremoved from
> testing already)
> Who should I contact to get those removed from there as well?

I am a bit confused by several messages. What are your current plans with the
gnuhealth package? I assumed until now, that you planned to integrate the
upcoming upstream release and then reupload to NEW.

> From: Emilien Klein <emilien@klein.st>
> To: 707632-done@bugs.debian.org
> Subject: Closing bug report
> Date: Sun, 29 Jun 2014 08:59:29 +0200
> 
> As GNU Health was removed from the archive, this bug report is "fixed".
> Closing bug report.
> 
> Mathias, I am confident that in case you are picking up the package
> [0] you will make sure to address your concerns ;)
> 
> Thanks for your help and comments on this package.
>    +Emilien
> [0] http://lists.gnu.org/archive/html/health/2014-06/msg00008.html

What do you mean by 'picking up'?

To avoid further confusion: the gnuhealth package will enter debian.tryton.org,
when it fits into the concept (as previously said, chances now are much better
as the package just provides the modules). One other point of this concept is a
clean upgrade path to Debian main packages. So I won't do any changes to an
existing package not maintained by me nor provide a conflicting one.

Cheers,
Mathias


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.