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