[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: GNUmed install made easy - maybe
From: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] Re: GNUmed install made easy - maybe |
Date: |
Tue, 20 Sep 2005 17:57:35 +0200 |
User-agent: |
KMail/1.8.2 |
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
- [Gnumed-devel] Dual-boot Windows XP / debian sarge, (continued)
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Horst Herb, 2005/09/17
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Karsten Hilbert, 2005/09/18
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Horst Herb, 2005/09/18
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Sebastian Hilbert, 2005/09/18
- [Gnumed-devel] strategies for machine & network account set-up (and klik?), J Busser, 2005/09/18
- [Gnumed-devel] Re: GNUmed install made easy - maybe, Andreas Tille, 2005/09/19
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, J Busser, 2005/09/20
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe,
Sebastian Hilbert <=
- Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Karsten Hilbert, 2005/09/22
Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Ian Haywood, 2005/09/17
[Gnumed-devel] Re: GNUmed install made easy - maybe, J Busser, 2005/09/20
Re: [Gnumed-devel] Re: GNUmed install made easy - maybe, Karsten Hilbert, 2005/09/22