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 <[email protected]>: > > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
