health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Should distribution packaging solve the installation/co


From: Chris
Subject: Re: [Health-dev] Should distribution packaging solve the installation/configuration issues our users are having?
Date: Wed, 11 Feb 2015 23:40:07 -0800
User-agent: Mutt/1.5.23 (2014-03-12)

Hiya!

Good point, Axel. I'm really not familiar with distro packaging, except
limited Arch PKGBUILDs, so I need to leave most of these decisions to
others. Hehe. I can take guidance and help out where I can. But I am
wondering if we should merge this thread with the other one on Debian
(since similar issues are being discussed), or create a new thread
devoted to this generalized issue?

-C

On 02/11/15, Axel Braun wrote:
> Hi all,
> 
> > Good to hear some thoughts on this. I've had similar thoughts to
> > Emilien. I think I want good packaging and robust sysadmin tools to
> > solve these pesky issues. Yet, I see where it probably won't solve
> > everything, Mathias made good points on this.
> 
> Full ack.
> But that can only cover the first step (Installation and resolution of all 
> dependencies).
> Configuration should be made by each sys-admin.
> 
> > However, Luis made a good point about documentation. I must admit I'm at
> > fault for thinking of the documentation last. Hehe.
> 
> Mathias used already that nice four letter acronym for this.... ;-)
> 
> > I think there is a middle way that is open for improvement. For example,
> > on the FHIR side, I haven't included a requirements.txt file so there
> > can be a one-line python command to install all the dependencies.
> > I could also include some Ansible, Supervisord, etc.  example config
> > files to help sysadmins. *And* update the documentation!  Things like
> > that.
> 
> The more generalized issue of this topic is - do we want to ship source code 
> to the users?
> Emilien mentioned:
> > Of course, us veteran developers and system administrators have no
> > problem setting all these things up, and doing the occasional
> 
> I disagree. Even if you are somewhat experienced it is a PITA.
> 
> Just did a cross check to install gnu health from the installation script. It 
> failed a couple of times for different reasons.
> 1) gcc not installed
> 2) python-devel not installed
> 3) OK, python-devel was not the problem, where is Python.h?
> 4) cleaning all installation directories after each step.
> 5) get me another beer please
> 6) shall I really continue to try?
> 7)....
> 
> This has a high level of potential to frustrate end-users.
> 
> So, having a distribution-specific package that makes use of the package 
> management takes away all this trouble from an end user by having the 
> dependencies solved once for everyone (instad of having each user and each 
> installation solving it.), see slides from TUL [1]
> 
> OpenBuildService is OpenSource and free to use. It builds Debian and Ubuntu 
> as 
> well (also on the reference server, build.opensuse.org), and by this can use 
> as a common repository.
> 
> Another way may be to use docker or some kind of technology. Sharoon 
> presented 
> a promising example on TUL.
> 
> Independent which technology or Distribution we use, important is that we 
> come 
> up with a user friendly approach to run GNU Health (and Tryton)
> 
> My 2c
> Axel
> 
> [1] http://downloads.tryton.org/TUL2014/TUL2014_OBS_und_SUSEStudio.odp
> 
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]