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://[EMAIL PROTECTED] My OS: Suse Linux. Geek by Nature, Linux by Choice _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
