On Mon, Jun 23, 2008 at 1:10 PM, MJ Ray <[EMAIL PROTECTED]> wrote: > Requiring modules that we're not actually going to use is also a bug > in Koha.
I think that misconstrues the situation somewhat. We don't know what the end user is going to use. We have certain requirements to provide certain capabilities. It is not inherently wrong for the default installation to be "maximum capability", even if (for example) one given user never prints barcodes, and another never authenticates to LDAP. If the dependency is a reliable, widely compatible perl module, it should be treated as a Koha dependency, even if the feature it supports is logically severable. That is to say, we don't need to break Koha into 100 bits with frequently overlapping but "optional" dependencies. Each optional fragment should exist only because its dependencies are problematic or impossible for users to install correctly. Like Schedule::At not working on Win32 (no "at" command) makes it optional. Specifically, I don't think the "cost" in HDD space is significant given the profile of the project right now. I don't think it is worthwhile to add any complexity where the main payoff is allowing the user to *potentially* get a 400KB smaller installation. I can imagine that things would be different if we were working on an embedded application, or bundling larger deps like mysql and postgress. I still support developing a better way of accounting for the optional dependencies we do have, or migrating them to the kind of perl dependency that is unobjectionable. --Joe Atzberger
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
