[OPEN-ILS-DEV] Getting there -- bootstrapping OpenSRF Client problem

[Mike Rylander]

On 12/16/06, Joshua Ferraro <jmf at liblime.com> wrote:
> On Sat, Dec 16, 2006 at 10:28:12AM -0500, Mike Rylander wrote:
> > >I've updated the CPAN bundles with the latest dependencies as listed
> > >on the wiki, should take a few hours for CPAN to update. I'll try to
> > >keep tabs on what's required, if you see anything missing let me know
> > >and I'll add it.
> >
> > Just so everyone knows, you MUST still follow the instructions on the
> > wiki, preferably derived from the Debian, Ubuntu or Gentoo docs, for
> > installing Perl dependencies, especially for the MARC::* related
> > modules and Javascript::Spidermonkey.  These bundles will not include
> > the correct versions of the MARC modules, as their maintainers have
> > not released updated versions, and it can not automate the
> > installation of JS::SM without a good bit of work, because E4X support
> > is required in Evergreen.
> Good point. So, shall I:
>
> 1. remove MARC::* and JS::SM from the bundles?
> 2. require specific versions in the bundle?
>         (which would throw warnings since they aren't on CPAN)

(1) is more correct, since it's not the JS::SM version that is the
problem, but the libjs version (cvs version required -- c'mon,
Mozilla! Give us a new release already!) and attendant build switches
for both the C and Perl parts.  However (more below)...

>
> Regarding the MARC::* stuff, we've a similar problem in the Koha
> project -- do we need to branch the CPAN modules so we can ease the
> installation process? MARC2::* ?
>

There have been talks of this before, but I think it's premature.
There are fixes that are already in CVS for the MARC stuff, and
forking just to get those without a longer term vision, or some
features that we could point to that are 1) really needed in the
MARC::* core and/or 2) not do-able without a big-ish rewrite
(requiring more work than the current maintainers/authers want to
support/perform) will likely end up causing harm (version and
dependency confusion) to the userbase of the MARC::* parts.  Let's try
applying some more pressure before we go down this road ... thar be
dragons here.  ;)

> > We want to make EG easy for anyone to install, and maybe we can start
> > by releasing the images/tarballs that PINES uses for its environment.
> > While not part of EG proper, it might simplify things for similar
> > environments.  For the time being these bundles may not be (and, for
> > some situations, provably aren't) the best way to accomplish the "easy
> > install" goal.
>
> What about creating a Debian Etch package for EG? One of the problematic
> parts of CPAN bundles is that they don't handle upstream non-perl
> dependencies (obviously), whereas a Debian package could. I'd be willing
> to devote some resources to this in the coming weeks if everyone thinks
> it'd be a good direction.

It's certainly a good idea longer term, but that, too, is premature, I
think.  We're in the process of identifying and removing some legacy
dependencies as part of creating the release procedure, and that will
likely take a while and be both experimental and iterative, so the
resources you supply would be (in some ways) wasted -- it's going to
be a moving target for the near future.

Evergreen is currently at release 1.0.1 and is very young in terms of
external interest.  While there's obviously lots of excitement about
it, we all have constraints on the resources we have to apply to
certain parts of the project.  That's not to say we shouldn't create a
solid, standard installation procedure, but just that we need to slow
down and consider a more holistic approach.

For instance, were the system written entirely in Perl then investing
a good deal of time in the bundles would be very worth while.  As it
stands, there are some very large components that are extremely
modular, and can (and should, depending on particular circumstances)
be replaced at will.

Take, for example, the Jabber server.  PINES uses ejabberd and we
haven't had any issues installing it from distro packages, but Dan
Scott ran into several problems trying to get the same packages
working in a similar environment, and these problems seem to stem from
issues in the ejabberd packaging.  PINES has tested jabberd2 (it works
well, but with slightly higher load in our environment), and then
there's chopchop (the jabbers server Bill built for OpenSRF), and
maybe WildFire, and several others.

Then there's the versioning of Class::DBI (the API for a couple things
changed subtly between 0.96 and 3.0), the integration of PgPool and
Slony-I in a clustered environment (obviously not needed for a small
test setup, but very important for production), the supported Apache
versions (and testing thereof), etc.

The point I want to make is that, because we rely on a broad set of
existing packages, some interchangable in ways we haven't even
imagined yet (Bizgress MPP, PGReplicator and eRServer are unexplored
options for Pg+PgPool+Slony-I), we may not ever have a single .deb or
ebuild or whatever for all of EG.  It's a worthy goal, but it's not
something that we can do right now (moving target, proper resource
allocation, etc), and it's very likely that we will end up creating a
build/install procedure that, while itself dependent on some
underlying (stable) dependencies, will be more project and environment
specific than a set of .debs.

I think the first step is for those of us wanting to create a more
streamlined installation procedure to use the instructions that exist
to install EG, and start identifying gross commonalities in the steps.
 In addition, "we" need to get the PINES blobs out there so you guys
can see what we've done.  Let's all get a feel for the bigger
installation picture, and then we'll have a better feel for what's a
good (stable, group-able) target for starting this.

>
> > We want to release early and often, but we only want to release working
> > code.
>
> Cheers,
>
> --
> Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
> President, Technology       migration, training, maintenance, support
> LibLime                                Featuring Koha Open-Source ILS
> jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
>


-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org