Re: Any volunteer to update GNUHealth packages
Hi Emilien,
On Mon, Feb 09, 2015 at 09:17:08AM +0100, Emilien Klein wrote:
> Hi team,
>
> 2015-02-09 8:40 GMT+01:00 Andreas Tille <andreas@an3as.eu>:
> > Hi,
> >
> > GNUHealth 2.8.1 was released which is using tryton 3.4.0. We lost the
> > official GNUHealth package recently due to incompatibilities with
> > tryton. Any volunteer to prepare a package for exoerimental is more
> > than welcome.
> >
> > Kind regards
> >
> > Andreas.
>
> The compatibility issues due to the strict dependency of GNU Health on
> a specific version of Tryton is a problem that is not solved. Tryton
> 3.4.0 was released on 2014-10-20 [0], with a release cycle of 6 months
> we will face this version incompatibility issue in about 2 months
> again.
> At any point in time, when you look at the most recent GNU Health
> version you have a very high probability that there already is a newer
> (and thus incompatible) Tryton version out. As I had investigated [2]
> looking at the 9 months between 2013-04-22 and 2014-01-26, the latest
> version of GNU Health was depending on the then last version of Tryton
> only for one month.
>
> [0] http://www.tryton.org/posts/new-tryton-release-34.html
> [1] http://lists.gnu.org/archive/html/health-dev/2014-01/msg00042.html
Thanks for the reminder of this issue. My idea was that we should at
least try to enable people to get some updated packaging in experimental
which could work with a pinning to tryton from snapshot.debian.org. I'm
aware that this is a very weak thing. However, the work time you spent
into the previous versions should be rewarded somehow by keeping it at
some current state - perhaps there might be a better solution for
versioned tryton dependencies in the future which would enable us to
come up with something sensible in a short time frame.
> Aside from this issue, there was also the question of what should the
> package be?
>
> My vision was to provide a package that would allow the user to start
> using the application out of the box, without needing to fiddle with
> both Postgres' and Tryton's configuration files. The package obviously
> still allowed you do so if you want to, just answer no to the prompt
> if the installer should create a database. But upstream indicated
> [2]they prefer all their users to install the software using the
> upstream-provided install bash script, so as to have a uniform way in
> which the software is installed. Reasoning is that it helps with bug
> investigation when issues arise.
Uhmmm, assuming that an upstream-provided install bash script would lead
to an uniform way in which the software is installed is IMHO naïve.
> Debian is known to path upstream software to make it fit its vision of
> how an OS should be, making sure all software is installed in a
> uniform way. I know some upstreams don't like that. Not sure how this
> should be handled further, ideas welcome.
I'm not sure whether this is a good idea but I would try to teach
upstream about software installation be referencing the UpstreamGuide[3]
However, I'm not sure if our point of view is that convincing if we
commit the fact that we are not even able to create a proper package due
to the Tryton release cycle issue.
> [2] https://lists.debian.org/debian-med/2014/03/msg00208.html
>
> A final discussion point was with the Debian Tryton maintainer
> (Matthias, feel free to comment, as I believe you are on the d-med
> mailing list): Tryton is developed and packaged with separate
> tarball/.deb for each module. GNU Health is provided as one single
> tarball. Matthias was of the opinion that the gnuhealth software
> should be provided as separate .deb, to allow separate installation.
> His motivation was security, to not install packages that are not
> needed.
I'm personally a friend of using unchanged upstream tarball (if
possible) and modularised binary packages in "sensible" parts. Usually
this "sensible" heavily depends from the maintainer opinion and I have
not yet found a good definition for it. Since I neither have any idea
about Tryton nor about GNUHealth I do not feel competent to answer this
question.
> Aside from this being somewhat more cumbersome, it could still be
> reached by having one source package output multiple binary package,
> possibly also with one generic gnuhealth package that would depend on
> the essential/wanted binary packages. Thoughts?
This sounds reasonable to me.
> Before/if I start working on that package again, I want to make sure
> we reach a consensus (this time ;) )
:-)
Thanks for your educated explanation and discussion triggering
Andreas.
[3] https://wiki.debian.org/UpstreamGuide
--
http://fam-tille.de
Reply to: