Re: Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)
Hi Mathias and all, 2014-06-29 16:49 GMT+02:00 Mathias Behrle mathi...@m9s.biz: * Emilien Klein: Force removal of gnuhealth* packages in sid? (Was: Re: GNU Health autoremove from testing) (Sun, 29 Jun 2014 09:09:30 +0200): Hi Emilien, 2014-06-10 14:46 GMT+02:00 Emilien Klein emilien+deb...@klein.st: The packages gnuhealth-server and gnuhealth-client will have to be removed from sid (and from testing once the new package migrates to testing). The removal of the binary packages is automatically done once the package with the changed binary package names will be uploaded. I guess we can just wait for the autoremoval period to lapse, and the package will be removed automatically. Since there will be no upload of the newest version of the source package (newer Tryton version preventing building of GNU Health 2.4.X), the change in binary names will not be observed by the release system. I suppose I have to take manual action to remove that package from sid as well (the gnuhealth* packages were autoremoved from testing already) Who should I contact to get those removed from there as well? I am a bit confused by several messages. What are your current plans with the gnuhealth package? I assumed until now, that you planned to integrate the upcoming upstream release and then reupload to NEW. Sorry if the lower half of this post wasn't clear enough: https://lists.debian.org/debian-med/2014/06/msg00056.html My plan for the gnuhealth package in Debian is to remove the package from the repository. In fact, I filed the ROM bug yesterday for removal from unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762136 As indicated in my June post (first link above), the main reason for this is the strict dependency of GNU Health on specific versions of Tryton, and the incompatibilities in release schedules between the 2 projects, as you've mentioned in [0] yourself. A discussion with upstream [1] to propose bringing the 2 release cycles closer didn't improve the situation. I've analyzed that before [2], most of the time the latest GNU Health version doesn't run on the latest version of Tryton (but the version prior to that). You can see the dates mentioned in the previous post, the summarizing quote of which is So 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://lists.alioth.debian.org/pipermail/tryton-debian/2014-May/002303.html [1] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00015.html [2] http://lists.gnu.org/archive/html/health-dev/2014-01/msg00042.html Other reasons for not pushing harder on my side include: - Upstream indicated [3] that they see not much benefit in having the Debian package manage the database, but would rather want the Debian package to just install the files, created the OS user (which runs contradictory to your preference to run only one Tryton server under the user provided by the tryton-server package) and install bashrc files for that user, in effect mimicking the upstream-provided installation script (motivation is uniformity in installation, user under which the service runs, etc. over all installations of GNU Health, regardless of the distribution on which it was installed) - I don't see the benefit of providing a package which basically only drops the source file on the disk, but for which the rest of the setup needs to be done manually. I do understand this could be useful to some users, and in fact the original form of the package provided that (just respond no to the question if the database should be managed by the installation process), but just uncompressing a tarball is not what a Debian package should look like in my opinion. [3] https://lists.debian.org/debian-med/2014/03/msg00208.html So rather than maintaining a package that: - can't be build a large fraction of the time in unstable; - doesn't fit upstream's vision on how it's software should be used; - doesn't fit my vision of what a Debian package should do for its user (i.e. usable out-of-the box, tweakable to any extent if needed); I have decided not to spend my free time on the Debian package, but rather see how I can contribute more closely directly upstream (e.g. helping with HL7 implementation in GNU Health). That being said, looking at the number of posts in the past months on the project's lists of users that have installed the software, but can't make connection to the server, I remain convinced of the utility of a package in Debian and derivative distributions that allow a user to just install both server and client side with one command (`apt-get install gnuhealth` and run the client `gnuhealth`) remains valuable, definitely for people trying the software out. That's the first step in making the software known, a new user can try it out rather simply. Of course when you're satisfied and want to run it in PRD, you'll have to
Re: Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)
Hi, On Fri, Sep 19, 2014 at 01:14:11PM +0200, Emilien Klein wrote: As indicated in my June post (first link above), the main reason for this is the strict dependency of GNU Health on specific versions of Tryton, and the incompatibilities in release schedules between the 2 projects, as you've mentioned in [0] yourself. A discussion with upstream [1] to propose bringing the 2 release cycles closer didn't improve the situation. I've analyzed that before [2], most of the time the latest GNU Health version doesn't run on the latest version of Tryton (but the version prior to that). You can see the dates mentioned in the previous post, the summarizing quote of which is So 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://lists.alioth.debian.org/pipermail/tryton-debian/2014-May/002303.html [1] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00015.html [2] http://lists.gnu.org/archive/html/health-dev/2014-01/msg00042.html I admit I personally dont have any idea about Tryton and GNUHeath so my point might be a bit naive. I'd recommend watching the QA session with Linus at DebConf[1]. One major point he made is that you should never ever break an ABI. So if Tryton is a system that breaks its interface so frequently that you always need to use the latest version my personal recommendation would be: You should not use Tryton for business applications. As I said I might be naive / uninformed but for me personally this means that I do not want to touch this system. Other reasons for not pushing harder on my side include: - Upstream indicated [3] that they see not much benefit in having the Debian package manage the database, but would rather want the Debian package to just install the files, created the OS user (which runs contradictory to your preference to run only one Tryton server under the user provided by the tryton-server package) and install bashrc files for that user, in effect mimicking the upstream-provided installation script (motivation is uniformity in installation, user under which the service runs, etc. over all installations of GNU Health, regardless of the distribution on which it was installed) - I don't see the benefit of providing a package which basically only drops the source file on the disk, but for which the rest of the setup needs to be done manually. I do understand this could be useful to some users, and in fact the original form of the package provided that (just respond no to the question if the database should be managed by the installation process), but just uncompressing a tarball is not what a Debian package should look like in my opinion. [3] https://lists.debian.org/debian-med/2014/03/msg00208.html Since I had a similar discussion with the GNUmed authors where I had the same packagers attitude as you Emilien and the GNUmed authors followed the same idea as GNUHealth authors I think there must be something behind it. I actually realised that in the end it is way less work for me as a packager to follow their opinion which was reason enough to me to spend my time on other projects. So while not beeing finally convinced that they are right it is implemented according to their recommendation anyway. :-) That being said, looking at the number of posts in the past months on the project's lists of users that have installed the software, but can't make connection to the server, I remain convinced of the utility of a package in Debian and derivative distributions that allow a user to just install both server and client side with one command (`apt-get install gnuhealth` and run the client `gnuhealth`) remains valuable, definitely for people trying the software out. That's the first step in making the software known, a new user can try it out rather simply. Of course when you're satisfied and want to run it in PRD, you'll have to think better on your deployment and backup strategy. But there's no harm in e.g. having the package take an extra automatic backup of your database ;) +1 I meant inclusion in the Tryton Debian archive. Similar to what you've just indicated [4]. What exactly is the Tryton Debian archive. Mathias wrote about something outside main which I actually would call a restriction I would not like since you will miss all the QA stuff which makes a package for science and business applications really valuable. Debian is nit just a bunch if simple to install software but a distribution of *tested* software that fits *together* properly. [4] http://lists.alioth.debian.org/pipermail/tryton-debian/2014-September/002790.html I hope you don't get a negative feeling on my part from this message. I am still as enthusiastic about Debian [Med] and GNU Health, but I've come to realize that packaging in the official Debian repository currently has challenges, and that I feel my
Re: Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)
2014-09-19 15:58 GMT+02:00 Andreas Tille andr...@an3as.eu: Hi, On Fri, Sep 19, 2014 at 01:14:11PM +0200, Emilien Klein wrote: As indicated in my June post (first link above), the main reason for this is the strict dependency of GNU Health on specific versions of Tryton, and the incompatibilities in release schedules between the 2 projects, as you've mentioned in [0] yourself. A discussion with upstream [1] to propose bringing the 2 release cycles closer didn't improve the situation. I've analyzed that before [2], most of the time the latest GNU Health version doesn't run on the latest version of Tryton (but the version prior to that). You can see the dates mentioned in the previous post, the summarizing quote of which is So 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://lists.alioth.debian.org/pipermail/tryton-debian/2014-May/002303.html [1] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00015.html [2] http://lists.gnu.org/archive/html/health-dev/2014-01/msg00042.html I admit I personally dont have any idea about Tryton and GNUHeath so my point might be a bit naive. I'd recommend watching the QA session with Linus at DebConf[1]. One major point he made is that you should never ever break an ABI. So if Tryton is a system that breaks its interface so frequently that you always need to use the latest version my personal recommendation would be: You should not use Tryton for business applications. As I said I might be naive / uninformed but for me personally this means that I do not want to touch this system. Other reasons for not pushing harder on my side include: - Upstream indicated [3] that they see not much benefit in having the Debian package manage the database, but would rather want the Debian package to just install the files, created the OS user (which runs contradictory to your preference to run only one Tryton server under the user provided by the tryton-server package) and install bashrc files for that user, in effect mimicking the upstream-provided installation script (motivation is uniformity in installation, user under which the service runs, etc. over all installations of GNU Health, regardless of the distribution on which it was installed) - I don't see the benefit of providing a package which basically only drops the source file on the disk, but for which the rest of the setup needs to be done manually. I do understand this could be useful to some users, and in fact the original form of the package provided that (just respond no to the question if the database should be managed by the installation process), but just uncompressing a tarball is not what a Debian package should look like in my opinion. [3] https://lists.debian.org/debian-med/2014/03/msg00208.html Since I had a similar discussion with the GNUmed authors where I had the same packagers attitude as you Emilien and the GNUmed authors followed the same idea as GNUHealth authors I think there must be something behind it. I actually realised that in the end it is way less work for me as a packager to follow their opinion which was reason enough to me to spend my time on other projects. So while not beeing finally convinced that they are right it is implemented according to their recommendation anyway. :-) That being said, looking at the number of posts in the past months on the project's lists of users that have installed the software, but can't make connection to the server, I remain convinced of the utility of a package in Debian and derivative distributions that allow a user to just install both server and client side with one command (`apt-get install gnuhealth` and run the client `gnuhealth`) remains valuable, definitely for people trying the software out. That's the first step in making the software known, a new user can try it out rather simply. Of course when you're satisfied and want to run it in PRD, you'll have to think better on your deployment and backup strategy. But there's no harm in e.g. having the package take an extra automatic backup of your database ;) +1 I meant inclusion in the Tryton Debian archive. Similar to what you've just indicated [4]. What exactly is the Tryton Debian archive. Mathias wrote about something outside main which I actually would call a restriction I would not like since you will miss all the QA stuff which makes a package for science and business applications really valuable. It is an APT repository (not sure what the technical term is, but I'm sure you understand the meaning) maintained outside of Debian to make all Tryton releases available for the different Debian suites [outside] the main repository of Debian. [...] Note: Those packages are unofficial and you are using them at your own risk (as always). http://debian.tryton.org/debian/dists/
Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)
* Emilien Klein: Force removal of gnuhealth* packages in sid? (Was: Re: GNU Health autoremove from testing) (Sun, 29 Jun 2014 09:09:30 +0200): Hi Emilien, 2014-06-10 14:46 GMT+02:00 Emilien Klein emilien+deb...@klein.st: The packages gnuhealth-server and gnuhealth-client will have to be removed from sid (and from testing once the new package migrates to testing). The removal of the binary packages is automatically done once the package with the changed binary package names will be uploaded. I guess we can just wait for the autoremoval period to lapse, and the package will be removed automatically. Since there will be no upload of the newest version of the source package (newer Tryton version preventing building of GNU Health 2.4.X), the change in binary names will not be observed by the release system. I suppose I have to take manual action to remove that package from sid as well (the gnuhealth* packages were autoremoved from testing already) Who should I contact to get those removed from there as well? I am a bit confused by several messages. What are your current plans with the gnuhealth package? I assumed until now, that you planned to integrate the upcoming upstream release and then reupload to NEW. From: Emilien Klein emil...@klein.st To: 707632-d...@bugs.debian.org Subject: Closing bug report Date: Sun, 29 Jun 2014 08:59:29 +0200 As GNU Health was removed from the archive, this bug report is fixed. Closing bug report. Mathias, I am confident that in case you are picking up the package [0] you will make sure to address your concerns ;) Thanks for your help and comments on this package. +Emilien [0] http://lists.gnu.org/archive/html/health/2014-06/msg8.html What do you mean by 'picking up'? To avoid further confusion: the gnuhealth package will enter debian.tryton.org, when it fits into the concept (as previously said, chances now are much better as the package just provides the modules). One other point of this concept is a clean upgrade path to Debian main packages. So I won't do any changes to an existing package not maintained by me nor provide a conflicting one. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
