[Debian-med-packaging] [tryton-debian] GNU Health in Debian
Mathias Behrle
mbehrle at m9s.biz
Thu May 9 20:09:00 UTC 2013
* Emilien Klein: " Re: [tryton-debian] GNU Health in Debian" (Thu, 9 May 2013
14:34:20 +0200):
As promised here comes my review of gnuhealth as in trunk [1]:
1) General layout:
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.
Filed under [3].
2) Maintenance for different Tryton versions
There is a reason behind debian.tryton.org. Up to now there is no way to map
the release *and* maintenance cycle of Tryton relases to Debian releases.
Tryton has a strict timebased release cycle of 6 months, Debian is releasing
appr. all 2 years. Tryton publishes bugfix releases for 2 years for every
stable version. There is no way to get those bugfix releases into a stable
release. That is exactly the point, why we are providing for the sake
of Tryton users Debian packages for Tryton besides the official repositories.
Until now you are forced to upgrade your users to Tryton bleeding edge,
because this is, what will be in unstable. Do you really want to take this
risk for users, that depend on the reliablity of their application and data
(medical centers, doctors, etc.)? I certainly won't recommend that, and as
Tryton contributors since version 1.0 never would do it with our customers.
Perhaps the upcoming layout of PPA/DPA/*PA will allow to host those packages
in Debian itself, but it will depend on the final layout.
Of course we are offering you to maintain the gnuhealth packages on
debian.tryton.org together with the possibility to publish versions suitable
for different Tryton and Debian releases (besides the versions in Debian
itself).
We are using the packaging workflow from git-stuff. If you are interested
you are welcome.
Filed under [4].
3) Copyright
Please review the package for used licenses.
debian/copyright misses at least:
- Copyright holder Cédric Krier (setup.py)
- Copyright holder *and* license for icons/*.svg
Besides that I would have appreciated to credit the work of the Tryton
maintainers, at least init script and default are taken from tryton-server.
Filed under [5].
4) System user for the server
Please drop creation and usage of the gnuhealth user.
While it is obviously preferable to run a tryton server under a user
account, it is generally not a good idea to run different servers under
different users.
trytond uses unoconv for document conversion. unoconv can be run as a
service, which is preferable for performance reasons. To connect a tryton
server to an unoconv session it must be run under the same user.
Running the server under a different user as the tryton user created from
tryton-server package itself IMO is needless and counterproductive. Probably
this idea is a relict from GNU Health wiki, which is inspired from the wiki
on tryton.org, where we are describing a setup, when running trytond from
*sources*(!).
Filed under [6].
5) Patch for man page
This patch for just a typo seems a little bit overkill for me, but anyway:
Did you forward it to upstream? Could you please insert DEP3 headers [7]?
6) gnuhealth-client package
What is the resoning behind creating the planned gnuhealth-client package?
Is it really heavily customized or is this just to rename tryton-client to
gnuhealth-client?
7) TODO.Debian is outdated
tryton-modules-stock-lot is downloadable for version 2.6 as well as 2.8
for wheezy and for testing/unstable from an aptable repository on
debian.tryton.org. 2.8 hopefully soon in Debian itself...;)
Those are my first impressions on the gnuhealth package.
Good luck with gnuhealth!
Mathias
> 2013/5/9 Mathias Behrle <mbehrle at m9s.biz>:
> [...]
>> In the meantime I discovered, that gnuhealth was packaged and uploaded to
>> experimental. The package for me has important issues. I am wondering, why
>> nobody got in contact with the maintainer of the other Tryton packages. I
>> will post my review and concerns on the gnuhealth package in another mail,
>> hopefully today.
>
> I'll be happy to read your comments. Please note that the version
> uploaded to experimental (gnuhealth 1.8.0-1) is already pretty old,
> i.e. in our repository we're working on version 1.8.1-1. One important
> and visible change is the renaming of the binary package from
> gnuhealth to gnuhealth-.server. Have a look at the SVN repo [0] before
> providing your feedback.
> Please make sure to CC the Debian Med team, as the GNU Health package
> is team-maintained (I just happen to be doing most changes currently,
> but the package was started before my contributions)
> I'll make a guess that you will have something to say about the
> gnuhealth-server service? ;)
>
> As a general comment: all feedback is welcome. This package is still
> pretty new, and far from being complete. Plans include creating 2 more
> binary packages (gnuhealth-client and gnuhealth, next to the current
> gnuhealth-server) that will allow for easy installation of either only
> the server components, the client components, or all components on the
> same machine. The reasoning behind the separate gnuhealth-server
> daemon is to be able to provide Tryton with a customized configuration
> (such as database info and custom port), to reduce the impact on an
> eventual Tryton server already running on that machine.
>
> +Emilien
> [0]
[1]
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnuhealth/trunk/debian/
[2] http://ftp.gnu.org/gnu/health/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707632
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707637
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707638
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707639
[7] http://dep.debian.net/deps/dep3/
--
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
-------------- 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/20130509/e602ef93/attachment.pgp>
More information about the Debian-med-packaging
mailing list