[Debian-med-packaging] Packaging GNU Health

[Emilien Klein]

Hi Andreas,

2012/11/30 Andreas Tille <andreas at an3as.eu>:
> Hi Emilien,
>
> On Thu, Nov 29, 2012 at 10:59:43PM +0100, Emilien Klein wrote:
>> Hey Debian Med team,
>>
>> After numerous fresh reinstalls to make sure the
>> installation/configuration instructions in debian/README.Debian are
>> correct, I've gotten to the point where the GNU Health package is
>> ready for review.
>
> Thanks for working on this.  I had a *very* *quick* look (more close
> look might need some time).

Thanks for your reactivity.

> 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.
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).

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).

>> I've used Andreas' files as a starting point, and committed my changes
>> to the svn [0]. I've also created the ITP bug [1].
>
> Fine.
>
>> A few points key points (but please do check all my modifications):
>> - I've removed the health_qrcodes module from the installation, as I
>> wasn't able to get the proper Python package installed, and leaving
>> the health_qrcodes module resulted in exceptions when running Tryton.
>
> What exactly do you mean by "the proper Python package" and what was the
> actual problem?  A quick search revealed
>
>> Not sure it's packaged for Debian, there are a few Python QR Codes
>> modules, but none seemed to provide the qrcode module... Will try to
>> investigate more in the coming weeks.
>
> $ 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

>> - I've explicitly turned of testing (it wasn't running anyway, but
>> making it explicit seems better). Reason is that to be able to test,
>> you need to have a proper database set up. Not sure how this should be
>> handled though.
>
> 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)

>> - In light of the recent changes [2] I've removed the
>> DM-Upload-Allowed tag in debian/control.
>
> Fine.
>
>> - I've changed the values of files debian/compat and Standards-Version
>> in debian/control to what is currently being given when you start a
>> new package with dh_make. Not sure why Andreas' values were higher?
>
> For new packages I prefer to use the latest debhelper compatibility
> level (currently 9) and latest Debian Policy version 3.9.4.
>
>> As stated in debian/TODO.Debian, the current version of GNU Health
>> depends on Tryton 2.4.X. The current version of GNU Health requires
>> Tryton 2.4 (exactly) while at the moment Tryton 2.2 is in testing and
>> 2.6 in experimental. So this package can not be uploaded directly to
>> sid, but as soon as GNU Health 1.8 comes out (planned end of the month
>> [3]) updating the package should be relatively straight forward.
>> Note: due to this unmet dependency in sid, building the package in a
>> chroot (pdebuild) will fail.
>
> 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.

>> FYI this is how I was able to test the package, using the Tryton 2.4
>> version that was in experimental last month (might be useful if you
>> want to test building the package, and the setup instructions)
>>
>> Add snapshot for old experimental in /etc/apt/sources.list:
>> deb http://snapshot.debian.org/archive/debian/20121022T125613Z/
>> experimental main
>
> I'll try this - thanks for the hint.
>
>> 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.

Let me know ;)
   +Emilien