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

[Mike Rylander]

On 12/16/06, Don McMorris <don.mcmorris at gmail.com> wrote:
> <!--/me snips a few KB here and there ;)-->
>
> > > Also, unless you updated the packages from the recent Debian or Ubuntu
> > > documentation or from a fresh install of your own, as opposed to the
> > > generic "Perl Modules" page, you most likely missed plenty of
> > > dependencies.  Dan Scott and Don McMorris have (quite thankfully!)
> > > done a lot of work fleshing out the installation docs, having gone
> > > through it completely now.
>
> Thanks for the credit Mike! I appreciate it.
>
> > Ahh, OK, so they've got it installed now? Cool!
>
> I don't have it installed quite yet.  I think the last time I tried
> the install was pre-Beta.  I might work on it again soon, depending on
> how things in other areas go.
> Following the instructions in the Wiki exactly, I got a near working
> install.  I did run into some problems at that stage, as the progress
> was so swift that documentation became outdated almost daily.  This
> list helped greatly though, and V1.0 should mean that newer deps/etc.
> shouldn't come out as quickly (hopefully the documentation could be
> relevant for about 2 days now ;) ).

ha!  It is much more stable now (for many of the same reasons we
FINALLY cut 1.0), but like I mentioned, we need to /remove/ some deps
... that'll cause a chunk of the instability in addition to the other
bits I've mentioned.  We're also looking towards 1.2 (spring time,
hopefully), so backporting the dependency removal stuff to the 1.0
branch will be slightly delayed from the HEAD branch, and again, the
timeline is still somewhat undefined.

>
> > 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.
>
> I think Evergreen is still updated a little bit too quickly to have
> static packages.  However, something I would like to see is an
> Installation Toolkit (the "Fir Installation Toolkit", or FIT, in
> sticking with the pine-tree names ;)).  This would be a series of
> scripts that downloads the current code, checks and updates deps, and
> does a good amount of the configuration based on user input.  Updater
> scripts may also be helpful that update the core of Evergreen on
> occasion.
>

Right, that's the general shape of the thing I'm imagining, and we use
those ideas in part now for the staff client build as well as the DB
initiallation and bootstrapping config.

How about the KIT, for "Konifer Installation Toolkit"?  Other than
/bin/sh, ;) do you know of any particularly good frameworks for such a
beast?

> There are also a couple things at the Software Bounties pages
> (http://www.open-ils.org/dokuwiki/doku.php?id=sofware_bounties), such
> as:
> -> Move current process to GNU Build tools (Automake/Autoconf)
> -> A PROCESS for creating bootable LiveCD ("process" emphasis added by me)
> -> Help with OpenNCIP (http://www.openncip.org)
> Not on that list (but mentioned here some weeks back as I recall) was
> the building of a VMWare image of Evergreen.
>

Updated.  Thanks!

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