Re: [Health] OT: gnuhealth package in Debian (was: Problems with importing translation files in a VBox installation)

[Mathias Behrle]

* Luis Falcon: " Re: [Health] OT: gnuhealth package in Debian (was: Problems
  with importing translation files in a VBox installation)" (Thu, 12 Jun 2014
  08:31:18 -0500):

> Hi Mathias, all
> On Thu, 12 Jun 2014 11:45:38 +0200
> Mathias Behrle <address@hidden> wrote:
> 
> > * Cédric Krier: " Re: [Health] [HEALTH] Problems with importing
> > translation files in a VBox installation" (Thu, 12 Jun 2014 07:50:58
> > +0200):
> > 
> > Hi all,
> > 
> > several subjects were mixed up in this thread.
> > 
> > > On 11 Jun 22:54, Luis Falcon wrote:
> > > > Dear Emilien
> > > > 
> > > > On Wed, 11 Jun 2014 23:59:19 +0200
> > > > Emilien Klein <address@hidden> wrote:
> > > > 
> > > > > Hi Constantine,
> > > > > 
> > > > > 2014-06-11 22:29 GMT+02:00 Kostis Mousafiris
> > > > > <address@hidden>:
> > > > > > P.S.
> > > > > >
> > > > > > Also, IMHO, if anyone can, it would be highly desirable to
> > > > > > pre-package all this in a deb package-based distro and not in
> > > > > > an OpenSUSE environement :-D
> > > > > 
> > > > > GNU Health has been packaged for Debian, with version 2.4.1
> > > > > currently available in Debian Testing.
> > > > > But there are several issues that looks like that I'm going to
> > > > > remove the package from the Debian archive in the coming 2
> > > > > weeks, namely version conflicts with Tryton which renders the
> > > > > package unbuildable/uninstallable in Debian sid for 2/3 of the
> > > > > year.
> > > > This does not make sense.
> > 
> > True. The current gnuhealth package is due to uninstallation form the
> > archive, becuase it fails with piuparts (an installation testing
> > tool). It is basically impossible for Emilien to fix this package,
> > because it can not be built against tryton 3.0 any more (3.2 sitting
> > in sid).
> As Cedric said, Debian packaging system should be able to have to
> different versions of a package, like Tryton.

Of course those things can be done in Debian, but not all that can be done is
also opportune to be done. Just think, that a package in Debian has to be
supported security wise for their lifetime. That is much longer than e.g.
Tryton or GnuHealth are providing support for their releases, so this support is
up to the package maintainer. To not run into maintenance hell, the support of
parallel versions of a piece of software has to be evaluated rather strictly,
for good reasons.
 
> > Emilien decided to fix the package in removing those components, that
> > tried to make the package work "out of the box". To say the truth, I
> > am one of those not being sad about that, because I had several
> > issues with that setup. The upcoming gnuhealth package will just
> > install the modules on the system, which for me is the proper way. So
> > the future gnuhealth package (due to upload with availability of
> > gnuhealth for Tryton 3.2) for me is in better shape as before.
> Great !
> > > > In a similar manner that python2 and python3 can co-exist on the
> > > > same system, you can perfectly have two versions of Tryton or GNU
> > > > Health. 
> > > 
> > > For now, it is not really possible to have 2 different series of
> > > Tryton installed on the same «site-packages». That's the problem of
> > > Debian packages. But I think Debian packager could provide 2
> > > packages (not installable both together) or more packages for each
> > > supported Tryton series. This will allow for those who have
> > > installed GNU Health to stay on the old series until the support of
> > > the new series came out. It will also give more flexibility to the
> > > user to stick on a specific series for a while instead of forcing
> > > everyone to upgrade.
> You can just use the standard installation method [1] - which allows
> co-existing versions of Tryton - , and enjoy GNU Health in your favorite
> Libre Operating System or GNU/Linux distro :)

Of course you can install software aside from the package manager of your
distribution. But you should really only do it, if you are aware of the
consequences. After a short glance at gnuhealth_install.sh I see - correct me,
if I should be wrong - , that the server installation uses pip to install
python packages without using a virtual environment. This will probably
mostly work, if the machine is dedicated alone for running gnuhealth. As soon
as you will install e.g. another package depending on another version of a
python package you will be in trouble. A sane solution for me would be to
provide something like a fabric file, creating the virtualenv etc.. This still
leaves the user to care for updates or securtiy fixes separately from the system
updates.

> > Exactly. That was evaluated to do and still is in the pipeline. There
> > is a trade-off to be handled between effort, distribution conventions
> > and popularity of the package.
> > 
> > That said, I want to emphasize, that it is currently very well
> > possible to stick with specific Tryton versions via
> > debian.tryton.org. After some testing of the new gnuhealth package I
> > will consider to put it also in the backports section. The latter for
> > me seems to be the preferable way, as it will be possible to provide
> > gnuhealth for quite more different scenarios than it could be in
> > Debian main.
> Great ! Good to know that GNU Health 2.6 will be considered in Debian.
> 
> Please consider using the gnuhealth installer as the base for the
> installation package in your distro. It much easier to interact with the
> community, following the "official" installation instructions,
> reporting issues, etc..
> 
> This subject has been long debated, so I won't get into it again :)

So I won't add to the arguments above...;)
 
> That said, I know there are different views on this, and I respect each
> operating system/distro way of packaging / installing GNU Health. 
> 
> Thanks a lot to all of you for your suggestions and support !

Thanks for your work on gnuhealth!
 
> 1.- http://en.wikibooks.org/w/index.php?title=GNU_Health/Installation
> > 
> > 
> 



-- 

    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
Description: PGP signature