[OPEN-ILS-DEV] Gentoo/portage tree for evergreen

[Bill Erickson]

On 1/2/07, Eric Lesage <lesagee at iro.umontreal.ca> wrote:
>
> Hi,
>
> For those who might be interested, following Bill's suggestion, I've
> finally published my Portage tree which includes the ebuilds for evergreen
> 1.0.1, spidermonkey (with a E4X-capable snapshot) and the various Perl
> modules which are not in the official Gentoo tree.
>
> You can find it at: http://www.iro.umontreal.ca/~lesagee/openils


Excellent!

Please keep the following in mind:
>
> - I've not even attempted to try the staff client.


Fortunately, building the staff client is the easiest part.

- I've not finished configuring the system either, but I got as far with
> this ebuild than with the source tarball.
>
> - When downloading applications, portage usually looks in a bunch of
> gentoo mirrors first. However, for out-of-tree ebuilds, this is fruitless.
> Eventually portage gets to the real source URL and the download will
> succeed then.
>
> - The libdbi that will wind up being used is the version that happens to
> be stable on your platform according to the official tree. Unfortunately,
> I've encountered too many problems at this time to include a custom
> version.


Hmm.  Does the custom version of libdbi install OK if it's installed after
the ebuild runs?

- The jabber server being used will depend on whether the
> virtual/jabber-server has been fulfilled on your system. If not, a default
> according to your profile will get selected. If you want a particular
> server, please emerge it first. (Note: this will probably get entirely
> removed later since chopchop gets the job done).


Disclaimer:  chopchop is designed for testing purposes.  It accepts any
authentication and has been known to freeze-up at high throughput.  It is
very easy to use, though, and works great for testing.

- The tree will decompress in a openils subdirectory. I've put mine in
> /usr/local/portage/openils, and added that to my /etc/make.conf.
>
> - I've tested on amd64 only (but it should work on x86 too).
>
> - The layout of the install differs considerably from the stock tarball:
> I consider anything installed by portage to be a system package, so I've
> followed the conventions for file locations as much as possible:
>
> System binaries in /usr/libexec/openils/bin
> CGI binaries in /usr/libexec/openils/cgi-bin
> Config in /etc/openils
> Logs in /var/log/openils
> C libraries in /usr/lib or /usr/lib64
> Perl modules in /usr/lib[64]/perl5/vendor_perl/[yourperlversion]
> Most of the rest in /var/lib/openils
>
> As a side-effect, PERL5LIB is no longer needed in the mod_perl
> environment.
>
> The use of /usr/libexec is perhaps most subject to debate. Arguably, some
> of those binaries should probably go in /usr/sbin or /usr/bin. I've
> decided to let them all live together until the source tarball itself
> supports different directories.
>
> - Currently, it's rather kludgy: an install.conf is written dynamically
> and various hard-coded paths are changed all around in the distribution. I
> expect most of this will no longer be needed if/when a standard autotools
> build process gets used.


Absolutely.

- Missing: various init.d scripts to have it run on boot. This also brings
> the question of whether a single monolithic ebuild is right for all those
> programs (in particular, chopchop could be chopped away ;-)). I guess for
> now it's not too important. However, if you customize your opensrf_all
> script, bear in mind that it will get overwritten each time you reinstall.


Another side note:  there is a new script called osrf_ctl.sh, which is the
successor to opensrf_all.  It's a cleaner script, has more fine-grained
actions, and depends on the environment and runtime flags as opposed to
hard-coded paths.  It also has no knownledge of the jabber server, so when
you do a full restart, you don't have to wait on the jabber server to
restart (since there's rarely a reason to restart it, anyway).

Example:

osrf_ctl.sh -d /tmp/ -p /openils/conf/bootstrap.conf -c
/openils/conf/opensrf_core.xml -a start_all

Run with no options to see a list of commands.

I would like to eventually deprecate opensrf_all.

So, that's it. Comments are welcome. I'll try to be responsive, but please
> remember I am not affiliated with the evergreen project.


Nice work :)  I'm sure others will find this very useful.

Happy New Year,


You too...

--
> Eric Lesage


-bill






-- 
Bill Erickson
PINES Systems Developer
Georgia Public Library Service
billserickson at gmail.com
http://open-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070103/121bd950/attachment.html