[Debian-med-packaging] Packaging GNU Health

[Andreas Tille]

Hi Emilien,

On Fri, Nov 30, 2012 at 10:54:55AM +0100, Emilien Klein wrote:
> > What I can say is that my vision of a
> > proper Debian package is more like *implementing* what is written inside
> > debian/README.Debian rather than requiring the user to create some
> > system user, create database etc.  For this purpose the postinst and
> > prerm scripts can be used.  There is quite good support for initialising
> > databases by the package dbconfig-common even if this is a bit hard
> > start for a packaging beginner.
> 
> OK, makes good sense.
> It was nonetheless necessary to start this way, since it wasn't that
> straightforward to install from source (mainly due to the unhelpful
> dependency error message). What might also be needed is to check the
> PostgreSQL settings, as I've had to lower the security to make Tryton
> able to communicate with it, but that's maybe more something for the
> Tryton module.

Possibly.  I admit I do not even have any imagination what Tryton might
be - I just need to dive into this technique a bit.

> I'll check if a vanilla install of Tryton/PostgreSQL delivers good
> results (in all my tests I've always modified it, see instructions in
> README.Debian).

As far as I know editing pg_hba.conf is the only thing you can not do in
the package install process (policy strictly forbids fiddling around
with other packages config files).  It would be *really* great if there
would be some kind of pg_hba.d/ mechanism where you could simply drop
single configuration lines.  (I have no idea whether this feature was
requested in the bug tracker at some point in time - but it would be
really helpful.)
 
> Overall, it seems a good idea to do all that work for the user (at
> least user creation, and database initialization, they might still
> have to mark the modules for installation inside the UI though).

IMHO we should gain for this in a final stage - lets see how far we can
do this in a first step.

> > $ axi-cache search python qr code
> > 5 results found.
> > Results 1-5:
> > 100% python-qrencode - Python bindings for the Qrencode QR Code generator library
> > 91% python-qrtools - high level library for reading and generating QR codes
> > 90% python-zbar - bar code scanner and decoder (Python bindings)
> > 87% zbar-dbg - bar code scanner and decoder (debug)
> > 82% python-zbarpygtk - bar code scanner and decoder (PyGTK bindings)
> >
> > Which of these did you tried?
> 
> >From memory (was 2 weeks ago) I've installed both python-qrencode and
> python-qrtools, but none provided the qrcode module. I've asked the
> GNU Health developers which library they used, it's this one:
> http://pypi.python.org/pypi/qrcode/2.4.2

Hmmm, this does not seem to be packaged.  It might make sense to contact
the Debian python-modules team whether there is some reason for a lack
of this package (not good, other drop in replacement, whatever) and if
it is just because nobody did the work before we should probably
consider packaging it to not be forced to drop a GNU Health module for
no really good reason.
 
> > Well, setting up a database is complex but as I said above
> > dbconfig-common does help here to some extend.  We should at least give
> > it a try - may be this would also enable testing which would be great.
> 
> Valid point, running tests is better (if possible)
> 
> >
> > Good hint.  I might add experimental to my pbuilder sources.list.
> 
> If you do, make sure it's one from snapshot, as Tryton 2.6 is in
> current experimental.

Yep, understand that hint later but thanks for explicit clarification
anyway.
 
> >> Update the repos
> >> $ sudo aptitude -o Acquire::Check-Valid-Until=false update
> >>
> >> Install Tryton
> >> $ sudo aptitude -t experimental install tryton-modules-account-invoice
> >> tryton-modules-calendar
> >> $ sudo aptitude -t experimental --without-recommends install tryton-client
> >
> > Thanks for your work on this.  I hope I will manage to have a look next
> > week.
> 
> I saw you already responded on the naming issue on the ITP, thanks.

Yes.  'gnuhealth' is perfectly fine.  I just added the option to separate
words by '-' if wanted but I'm perfectly OK with your initial choice.
 
Kind regards

       Andreas. 

-- 
http://fam-tille.de