[Koha-devel] [Koha-patches] [PATCH] Bug 2176: adding SMS::Send to list of dependencies

[Joe Atzberger]

On Mon, Jun 23, 2008 at 5:49 PM, MJ Ray <mjr at phonecoop.coop> wrote:

> "Joe Atzberger" <ohiocore at gmail.com> wrote:
> > On Mon, Jun 23, 2008 at 1:10 PM, MJ Ray <mjr at phonecoop.coop> 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.
>
> Maybe not inherently wrong, but it is poor marketing, isn't it?


Not at all.  I never drive 100MPH or accelerate 0 to 60 in the shortest
possible time, but it is not "bad marketing" for Ford to have 100MPH on the
speedometer, and to publish their performance times.  Nobody will be scared
off by dependencies that install themselves cleanly in the background
without their intervention.


> > 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.
>
> I think that's taking things to the wrong extreme.  No need to break
> into a hundred parts, but expensive, awkward and/or niche things are
> probably worth being options - LDAP, image processing, cellphones...


This sounds like agreement.  I rewrote the LDAP handling for Koha and it's
dependencies are already optional.  The feedback from earlier versions of
the installer that indicated that was pretty poor though.  Something like:
You should run: perl -MCPAN -e 'install "If you want to authentify to LDAP,
install Net::LDAP on your system.";'

I.E., a message wrapped in the form of a broken command.  Hopefully whatever
method we use to account for optional components will be better than that.
I'm fairly agnostic about our options because perl doesn't seem to have a
"right" way of dealing with this.


> > 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 don't really understand this comment: the koha-en files take about
> 25Mb at present.  By contrast, Image::Magick and its core libraries
> add 4.5Mb, without including the various bits of X which probably
> won't be installed on headless webservers otherwise.  That's a
> significant 20% more.


I agree Image::Magick should be optional, but not because the 5MB is
particularly significant.  The main reason is that it cannot be reliably
installed (the CPAN version not compiling on Debian, for example).  Koha
loses exactly zero real users over 5MB.

You're comparison isn't apples-to-apples anyway.  You'd need to compare the
size of Koha's other system dependencies.  But you say disk space isn't a
main concern, so OK, we don't care about 5MB.

Then besides our method of accounting for optional deps, the other question
is how to categorize deps as friendly-enough-to-be-included or
problematic-enough-to-be-optional.  We should have one or more of the
following:

   1. Explicit criteria, so the developer knows which path to take.  For
   example, that PurePerl modules are OK.  This helps the developer know
   *before* the dep is added.
   2. Specific systems (OS's) that we are targeting, such that compatibility
   on all of them would be sufficient.  I want to acknowledge the tendency of
   this topic to drift off into OS wars and advise that we be strictly
   pragmatic.
   3. A vetting process for proposed deps, ideally including buildbots or
   other automated checks.  The automated steps help the developers catch
   problems *after* the dep is added (to test code, at least).

--Joe Atzberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20080625/50d32e27/attachment-0002.htm>
-------------- next part --------------
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel