Re: [Gnumed-devel] Re: GNUmed install made easy - maybe

[Sebastian Hilbert]

On Tuesday 20 September 2005 17:28, you wrote:
> On the subject of klik
>
> At 6:47 PM +0200 9/17/05, Andreas Tille wrote:
> >  > What you
> >  > have in mind might be some kind of testing / advertising for end
> >  > users.
>
> Even after debs are available, would klik have value for debian (or at
> least non-debian) distributions?
It sure has. Klick is not another obscure format. It simply is another way to 
install the same files. Instead of putting the files in places where they 
belong (filesystem) with root access you can *install* a single big file in 
your home directory. 

klick is not to replace debs or rpms org tgz. It is to try GNUmed or even 
multiple versions without messing with root priviledges. If you wnat to get 
rid of it you simply delete *one* file. And all will be gone. 

a klick file does not register itself anywhere yet. It cannot be updated 
automatically. Simply load the next version and place this one file right 
next to the first one. No dependeny conflicts or anything are to be expected.
>
> I am thinking
>
> 1) although a doctor may arrange for someone to support the practice
> management system the doctor might as a hobbiest or for home access
> to the practice info install or re-install Linux at home. If the
> support people prefer to have the practice members using some other
> distro, klik (if it better supports non-debian installs) could make
> it easier for the doctor to set up the access from home. If course
> now I think that is stupid because it is better to have their actual
> practice system appear as a default or at least selectable choice in
> the client which would not happen from a klik install. So we are back
> to klik only for GNUmed evaluation.
For me there is no use in finding the killer use case for klick. If the 
technology holds true to what they promise it will be easy for me to provide 
because the real work on packages is done by the Debian package. Klick just 
*repackages* a deb. It's that easy.

Think of it like this. If you screw up your properly installed client by 
deleting the wrong files as root or updating wxwidgets to some non-working 
version system-wide via apt-get update and you need to get up and running 
again because you have patients waiting. Just 

get the slef contained click image and the cleint will be ready. Once your 
support people arrive the can fix the preffered installation system wide.

>
> 2) but my second use-case was going to be for patches. So I am
> wondering whether, especially once GNUmed is in use, a critical patch
> particularly on a security or patient safety issue could be important
> to be implemented quickly and maybe faster than all distros can have
> a custom deb or other binary. Now you might say "well that is a job
> for the support person" but sometimes the right local support people
> are not always accessible quickly enough and if we are talking
> something about a client (and if we did succeed in getting enough
> doctors to use Linux from home) that would be a lot of home-based
> copies of clients that would not need to be remotely accessed by
> support people which could be a big advantage.
Yes and No. Klick needs a deb or rpm to build a klick binary from. So we still 
need to update at least one of them. 

It usually goes like this with packaging. It takes month to build the first 
package because before you build the package you usually build yourself a 
build environment first.

It took 6 month to build the tar.gz and Windows binaries because I invested 
the time to automate the build process. Now it may take a day to build new 
packages once a new GNUmed release is out. Compare building a package by hand 
in a week or so with building a package in minutes once you have your build 
environment ready.

By the way. All ! scripts to build uptodate tar.gz packages and windows 
binaries are in your CVS tree. So anyone potentially can setup a build 
environment with these scripts. 

I can only guess but I think the same goes for Andrea's debs. Once he gets a 
fresh tar.gz from me he can automagically build updated debs.

He does not even have to rely on me supplying the tar.gz. With the help of the 
scripts mentioned above he could even build those himself.

That's one reason why I continue to complain about this issue. There is not 
much magic involved in building packages. Especially the Windows packages 
could be built by a Windows user. There are many Windows users out there with 
good skills. 
-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice