Hi Koha's I was wondering. Has anyone made a Koha distro yet? Ie a live/install cd that you could just put the CD into the drive and have koha work? Cpan is koha's biggest downfall and while such a cd would not be easily upgraded, it would be good for those that struggle with Cpan and koha's installation regards Colin McDermott
Or, less drastically, simply incorporate the modules into the main scripts, or fork the modules so that they cannot be upgraded through cpan, and include the proper perl with koha. Make koha more monolithic, so that change is dependent on the koha developers only and the whole thing resides in /usr/koha or wherever. I'm sure this is impractical for some reason. Steve On Mon, Jan 5, 2009 at 12:59 PM, Colin <colmcd@optusnet.com.au> wrote:
Hi Koha's
I was wondering. Has anyone made a Koha distro yet? Ie a live/install cd that you could just put the CD into the drive and have koha work?
Cpan is koha's biggest downfall and while such a cd would not be easily upgraded, it would be good for those that struggle with Cpan and koha's installation
regards
Colin McDermott
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Steven Owley Technology Specialist Ohionet 614-486-2966 x19
LibLime had an Ubuntu-based Koha live CD at the 2008 code4lib conference. You would be surprised how out of date the thing is now. Previous to that there was an old Koha virtual machine image available for those that couldn't clear the installation hurdle. I think a VMware-compatible VM would serve most readily as an instantaneous "Now you have Koha" delivery mechanism. The problem is that it is much bigger and relies on somebody to host a multi-GB image. Nobody really wants to do that, so maybe it would help if we had a distributed filesharing mechanism like BitTorrent. And then there is the downside of converting some of the list traffic to questions about VMware/Xen administration and OS/desktop/flavor-of-the-month questions: "Why not my favorite OS?" Steve's idea of forking the dependencies so they cannot update from CPAN is, in my opinion, a net loss in efficiency and manageability. How would Koha hand down updates and bugfixes to those modules once installed? Do you propose Koha incorporate and git-track the *entire* perl dependency tree? What about compiled dependencies? The current work on "monolithization" is to build an appropriate debian package, which should satisfy ubuntu users also. I see that as the most useful and immediate jump to spur new user adoption (besides getting XML parsing to work on win32). --Joe On Mon, Jan 5, 2009 at 12:59 PM, Colin <colmcd@optusnet.com.au> wrote:
Hi Koha's
I was wondering. Has anyone made a Koha distro yet? Ie a live/install cd that you could just put the CD into the drive and have koha work?
Cpan is koha's biggest downfall and while such a cd would not be easily upgraded, it would be good for those that struggle with Cpan and koha's installation
regards
Colin McDermott
On Mon, Jan 5, 2009 at 3:25 PM, Joe Atzberger <ohiocore@gmail.com> wrote:
LibLime had an Ubuntu-based Koha live CD at the 2008 code4lib conference. You would be surprised how out of date the thing is now.
<snip>
Steve's idea of forking the dependencies so they cannot update from CPAN is, in my opinion, a net loss in efficiency and manageability. How would Koha hand down updates and bugfixes to those modules once installed? Do you propose Koha incorporate and git-track the entire perl dependency tree? What about compiled dependencies?
I think that I am proposing just that--the koha installation should be self-contained, and everything it needs to be run (if not built) within a given host OS should be in the distribution, including a custom-built perl, MySQL and Apache, statically-linked. Development should take place within those constraints, too. For handing down bugfixes and updates, surely git can do that. I do not see any advantage to Koha refusing to run properly because the default perl distribution on Debian is too new, as has been the case recently. It's "dll hell" all over again. I see big long-run advantages to a self-contained distribution from a maintenance standpoint. This is how III Millennium does it--for instance, there is a parallel installation of Apache in there, somewhere in that /iii directory, for no other reason than that Innovative can completely control it. MySQL too. I can do what I like with the OS, as long as I don't stomp over their open ports. But I bet this conversation has already happened a dozen times, and since I do not have the expertise to actually do all this, I will stop arguing for it, however inevitable I think it is. Steve
Steven Owley wrote:
I think that I am proposing just that--the koha installation should be self-contained, and everything it needs to be run (if not built) within a given host OS should be in the distribution, including a custom-built perl, MySQL and Apache, statically-linked. Development should take place within those constraints, too.
This is the most stable way to distrbute Koha. But I don't think it should be the only way. For one, we cannot come up with a so-called "static and dependable" install for every possible OS. Rather, I agree we should come up with one for, say, the top 10, i.e. most popular Linuxes, a Mac OS X version for Leopard and one for Windows XP (I do not want to contemplate Vista). The dangley bits of the Koha install task are along the following lines: (*) installation on a non-supported OS config, i.e. Linux/WEiRd0 distro (*) installation in a development environment(s) i.e. using git directly (*) multiple installs in a shared environment i.e. two Kohas in one namespace (*) multiple installs in virtual environments i.e. one Koha per virtual
But I bet this conversation has already happened a dozen times, and since I do not have the expertise to actually do all this, I will stop arguing for it, however inevitable I think it is.
The topic will not go away until the installation situation is resolved. As it stands, and judging from the number of comments and cries for help on this list, we have a way to go. I am in the process of writing up an RFC on the developer's Wiki that addresses as many of the different installation environments and situations I can think of. How can we / should we as a group proceed to discuss this RFC? For one thing, the discussion belongs on Koha-developers. Or is there room for input from librarians and non-techies ? cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Beauty is only skin deep, but ugly goes clean to the bone. -- Dorothy Parker
On 2009/01/7, at 12:45 PM, Rick Welykochy wrote:
Steven Owley wrote:
I think that I am proposing just that--the koha installation should be self-contained, and everything it needs to be run (if not built) within a given host OS should be in the distribution, including a custom-built perl, MySQL and Apache, statically-linked. Development should take place within those constraints, too.
This is the most stable way to distrbute Koha. But I don't think it should be the only way.
For one, we cannot come up with a so-called "static and dependable" install for every possible OS. Rather, I agree we should come up with one for, say, the top 10, i.e. most popular Linuxes, a Mac OS X version for Leopard and one for Windows XP (I do not want to contemplate Vista).
lets keep it simple - and stay focused on the koha debian package first then we can start designing the amazon-compile-cloud...
Slight OT for this thread, but for people who may be interested ... Mason James <mason.loves.sushi@gmail.com> writes:
lets keep it simple - and stay focused on the koha debian package first
I had to re-do the Koha install I had done couple of weeks back.(details were posted here). This time, I choose Debian _experimental_. Started with an etch netboot ISO on a USB stick, installed the base operating system, upgraded to testing and then to experimental. (I know, it IS very adventurous. People will fry me alive for using debian experimental on a production server; but Debian experimental is more stable than RHEL they wanted to implement Koha on). And installed Koha 3.00.00 from the tarball. I think the list in install_misc/debian.packages are incomplete, since Makefile.PL complained about missing dependencies. After running make and "make install", I had installed CGI::Session and some other perl libraries from CPAN. _after_ this, I found that experimental has 4.40-1 of CGI::Session, so went ahead and installed it. I was stuck for about half an hour, since I forgot to edit the NameVirtualHost directive in ports.conf. Otherwise, it took me about 3 hours in all to install the OS _and_ koha. (Downloads took a bit of time - I was downloading everything over a 512 Kbps connection). After all this, I now hear that somebody here (in Kerala - possibly a quasi-governmental organisation) is distributing a 2CD pack for installing Koha. One CD contains the OS (a live CD with option to install to the disk, presumably), and a CD containing Koha tarball. I am told that once the OS is installed, all the user needs to do is to pop in the CD and run a script, which will then do everything required. Hoo!!! -- Mahesh T. Pai || http://paivakil.blogspot.com The wisdom of nations lies in their proverbs, which are brief and pithy. --William Penn
Mason James wrote:
On 2009/01/7, at 12:45 PM, Rick Welykochy wrote:
Steven Owley wrote:
I think that I am proposing just that--the koha installation should be self-contained, and everything it needs to be run (if not built) within a given host OS should be in the distribution, including a custom-built perl, MySQL and Apache, statically-linked. Development should take place within those constraints, too.
This is the most stable way to distrbute Koha. But I don't think it should be the only way.
For one, we cannot come up with a so-called "static and dependable" install for every possible OS. Rather, I agree we should come up with one for, say, the top 10, i.e. most popular Linuxes, a Mac OS X version for Leopard and one for Windows XP (I do not want to contemplate Vista).
lets keep it simple - and stay focused on the koha debian package first
then we can start designing the amazon-compile-cloud... _______________________________________________
Wouldn't it be cool of Koha could run on top of Firebird?
Greg ducks, covers head with raincoat and walks away<<<
Greg Lawson Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506
On Wed, 2009-01-07 at 10:45 +1100, Rick Welykochy wrote:
But I bet this conversation has already happened a dozen times, and since I do not have the expertise to actually do all this, I will stop arguing for it, however inevitable I think it is.
The topic will not go away until the installation situation is resolved. As it stands, and judging from the number of comments and cries for help on this list, we have a way to go.
I am in the process of writing up an RFC on the developer's Wiki that addresses as many of the different installation environments and situations I can think of.
How can we / should we as a group proceed to discuss this RFC? For one thing, the discussion belongs on Koha-developers. Or is there room for input from librarians and non-techies ?
cheers rickw
I would imagine there is room for input from Librarians and non-techies, since they will be the eventual end-users. Or don't non-librarians and techies have room for that sort of input?
From what I've read on this list and gathered from other sources there is quite a lot of room for improvement to the installation process for Koha. I have just managed to install LAMP on Ubuntu 8.04 after several weeks of research. All went smoothly due to my extensive research and documentation before I actually started the install process. The same material I have been gathering for a Koha installation does not bode well for such a smooth process as with the LAMP installation.
I know there are companies such as LibLime that will handle the technical back-end of Koha, but not all companies can afford or will want to go that route. Also, the dev list can be quite overwhelming to the non-techies, such as myself. Just my thoughts. Thanks, John - a non-techie and non-librarian, but one tasked with installing and maintaining Koha.
participants (8)
-
Colin -
gsl -
Joe Atzberger -
John S. Moss -
Mason James -
paivakil＠gmail.com -
Rick Welykochy -
Steven Owley