Re: [Health-dev] GNU Health in Debian

[Mathias Behrle]

* Luis Falcon: " Re: [Health-dev] GNU Health in Debian" (Tue, 10 Feb 2015
  19:50:18 +0000):

Hi Luis,

> It's good to see you around ! 

Yeah, nice to hear your from you!

> On Tue, 10 Feb 2015 18:19:26 +0100
> Mathias Behrle <address@hidden> wrote:
> 
> > * Cédric Krier: " Re: [Health-dev] GNU Health in Debian" (Tue, 10 Feb
> > 2015 15:28:36 +0100):
> > 
> > > On 09 Feb 09:38, Emilien Klein wrote:
> > > > Hi Mathias and the GNU Health development team,
> > > > 
> > > > With the latest version of GNU Health released, the discussion
> > > > around packaging it in Debian (and thus all derivatives such as
> > > > Ubuntu) has started again.
> > > 
> > > For me, the solution will be to have many version of each package
> > > for each series. And thus using the dependency solver to select the
> > > right sets of versions. But I don't know if the Debian package
> > > system allow to do that.
> > 
> > JFTR: Since gnuhealth modules are just another set of Tryton modules,
> > there should be not a big problem to package them in the same generic
> > way as the other base modules. The infrastructure to allow for a
> > correct mapping of gnuhealth series -> tryton series -> debian
> > release, which so far is not possible to do on debian.org itself, was
> > built since a while on debian.tryton.org.
> > 
> > I launched a while ago the same question on this list [0] and got
> > really few feedback. While the procedure above for me would be the
> > way to go and I would do the packages (as already stated), I don't
> > see any value in investing my time in packages deprecated more or
> > less by upstream. Even more as Luis favors to my knowledge the
> > installation and maintenance of a gnuhealth installation by scripts.
> > The Pros and Cons of this concept can be discussed, but certainly I
> > don't want to get in the way of the project respectively its
> > maintainers.
> 
> Thanks so much for your suggestions. As I have mentioned in other
> occasions, although GNU Health relies heavily on Tryton, and is the
> framework for its modules, it has its own release process and specific
> tools.

I am completely aware ot this. 
Just as a side note: gnuhealth being tied so closely to a specific Tryton
version I would nevertheless recommend to adopt the Tryton versioning schema,
which IMHO would make things clearer and nicer from a distribution and
user point of view (I know I am getting on your nerves by repeating me on that
subject;), sorry for that...). 

> For instance, now we have tools such as gnuhealth-control that
> allows to make backups, apply patches and check the environment of the
> running host. 
> 
> We also have our own set of aliases, RC file, predefined filesystem
> structure, etc... 
> 
> So, in order to be able to run GNU Health in different Operating
> Systems, from GNU/Linux to BSD and their variants, we need to have a
> "standard" way of installation. For isntance, if the FSH of the
> installation is different, then the gnuhealth-control program will have
> problems applying patchsets or updating the tryton kernel.

Looking at the patchsets: what was the motivation to choose that way of
upgrading a gnuhealth installation instead of upgrading via pip from releases?
You are taking the heavy burden of maintaining tools usually provided by the
system. For me this seems to be a huge effort, for which I miss to see the
advantages (e.g. missing the check of signatures done by a package manager
(not yet by pip, yes)).

> Also, it's important to have follow a common way, so when reading the
> book, or submitting a bug or an issue, we all know how to track it.
> 
> My suggestion for packagers is to call the gnuhealth_install
> script.
> > 
> > So first question for me to be answered: are those packages welcome
> > at all or are they considered as irritating and distracting from the
> > supported installation way?
> 
> You guys are the experts on distro packages, bu I suppose that it's
> possible to create a Debian, Arch, Red Hat and their derivatives distros
> package based on the standard installation script, and keeping the RC
> files, structure and utilities.

It would be nice, if it were that simple.

Some thoughts on the install script:

Advantage:

- common handling of some aspects of a gnuhealth installation over several
  distributions

Disadvantages:

- bash is not the prefered shell of every admin and thus not available on each
  system
- the usage of a dedicated user on the system owning the Python virtual
  environment and using pip as package manager is a workaround to not conflict
  with system Python packages
  - pip is an awesome tool for development, but it is way inferior to the
    average distribution package manager, when it comes to manage conflicts
  - the dedicated user needs a shell: not something you usually want for the
    user who runs a daemon
  - no virtual environment is needed when integrating the application with the
    system's Python packages
- the control and start of a daemon is better integrated with system tools
  dedicated to that task (didn't find any hint how this is currently
  handled/recommended after a quick glance to the wiki)
- all dependencies are handled by the distribution packages, not only
  the Python deps
- installations independent from the package manager of the
  distribution must be maintained independently (security wise), read:
  additionaly to the system updates, and tend to be neglected
- if only a subset of modules is required, it is better to install only the
  needed ones: e.g. gnuhealth also doesn't need all Tryton base modules. The
  current setup via installation script is completely tied to the one idea of a
  gnuhealth system and installs always all modules. This means losing
  modularity at installation level.

Those points just coming to my mind, for sure this list is not exhaustive and
is not meant to be. It is only to show some advantages of a system integration
with the relative package management. For sure I don't want to convert someone
to use rather system tools, just wanted to throw in some hopefully valuable
arguments.

BTW: specific scripts (for bug reports, backups, etc.) can still be packaged
and used by the user from the command line (like he has to do now).

If after iterating over this list you should find it useful to have
distribution packages, just give a sign and I will try to do them for Debian in
the same way as for Tryton base modules (with the only difference, that I
would want to provide the packages solely via debian.tryton.org for already
represented reasons).

Cheers and all the best to you and gnuhealth!

Mathias

-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://www.m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

pgpAxyKAahqkm.pgp
Description: Digitale Signatur von OpenPGP