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

[Mike Rylander]

On 1/8/07, Eric Lesage <lesagee at iro.umontreal.ca> wrote:
[snip]
> With that I can say that I now successfully run evergreen (both client
> and server+middleware) on my own system. The corrected openils.xml file
> (in CVS) was invaluable to get all services running (thanks Bill).
>

Very, very nice.  Congrats and thank you!

> Now of course the staff client is built using a build id matching the
> server, and there is no way to cleanly install a staff client for a remote
> system without the whole shebang. I'm not sure it's worth spending much
> time on this given that everything may change with FIT. One can always
> decide not to run the server (both the debug and build application.ini are
> installed).
>

You can (and we do, for testing and dev at PINES) build a
"versionless" staff client.  This will connect to any server-side
bundle that has a particular setup, which Jason can describe (and I
can't :P).

> A few comments:
>
> - It's not obvious to have the system run under a non-superuser in
> PostgreSQL. You have to create the database with that user as owner,
> install tsearch2 and tablefunc as postgres, grant your user rights on the
> tsearch2 tables, then run the build-oils-db script using your user.
>

Your right, it is not obvious that you /should/ run as a
non-superuser, but there's no reason you can't -- there are situations
where going through those security hoops just isn't worth the time and
overhead.  Incidentally, I figured that test installations would be
just such a case.  This is one of those areas where there is plenty of
good information on the topic "out there", and the topic is so broad
that it's mostly outside the scope of our project.

I think it would be beneficial to add some pointers to various "best
practices" docs and to the Postgres documentation (would you like a
wiki account, winkwink), but every installation will have different
requirements for deployment, tuning and maintenance.  Database
administration is never fire-and-forget for any non-trivial
installation.

> - The usr_group-setup.cgi script and the staff client will not work if the
> permission.grp_tree table is empty. On my local config I just uncommented
> (and corrected) what was in 006.schema.permissions.sql (this change is not

What exactly was it that needed to be corrected?

> in the ebuild).
>

Heh ... prepare for more punting from me.

I've (quietly) deprecated the bootstrapping CGIs for that and many
other reasons.  They were a very early hack, and only ever meant to
allow the bare minimum.  If I (or Brad) didn't need something right
then, it didn't happen.

Fast forward a couple years and Bill starts experimenting with Django.
 He's got the underpinnings of a new, useful admin interface working
now, and I'm thinking it's going to have to be a required milestone
for either the 1.2 or 1.4 release.  We just need to figure out some DB
issues and then it needs to be fully fleshed out and a couple custom
handlers found or built for dealing with our tree-like structures.

> - The MARC dependencies that are installed are:
>   - MARC::Charset 0.95 (from CPAN)
>   - MARC::Record 2.0RC1 (from SourceForge)
>   - MARC::XML 0.83 (from CPAN)

I'm not sure if 2.0RC1 is the same as what's in CVS for MARC::Record,
to be honest.  The other two are fine.

We also have some code that may (or may not) depend on Class::DBI
0.96/3.0.1.  I just now learned about Class::DBI::Frozen::301, which
is a neat idea for those stuck in our situation and may be an option
for the short term.  I'm planning to convert to DBIx::Class whenever
there's time for some planning, but it's not critical right now as
most of the basic search and retrieval is handled by the libdbi based
CStore application.

>
> There were the latest versions I could find, and seemed correct based on
> the wiki, but recent postings to the mailing list would indicate that CVS
> versions of some of those may be required. Does this apply to the 1.0.1
> release as well?
>

It applies globally for now, and for the foreseeable future.  FIT and
any distro/OS specific packages will need to take these into account.
Luckily, filling crazy dependencies should be a one-time thing.  ;-)

> As said above, I understand some/all of this work may have to be redone
> when the configuration/installation management system will be in place.
> But in the meantime, I was wondering if there were more immediate plans
> (eg. for 1.0.2 and, I suppose, a db upgrade script)?
>

I've been threatening to package 1.0.2 for the last week or so, which
would have some fairly significant bug fixes, but we're suffering from
"just ONE MORE THING"-itis right now.  Look for it by next week (I
think).

As for DB upgrades, the only thing that changed was the addition of
couple reporting schema support views, and one reporting-only money
schema view.  Hmm... come to think of it, reporter-schema.sql isn't
installed by the current scripts, so there's not much to upgrade from
a base install. :)

(That's actually by design, by the way.  The reporter schema is only
to be installed on the reporting server, which would normally be a
replica in a production environment.  I just haven't gotten around to
building the the reporting installation bits ... and I may not, now
that we've started talking about FIT.)

However, you point is well taken.  We need to think seriously about
how we should go about creating version-to-version upgrade scripts.
This will obviously need to be a big part of FIT, but we will need
something in the short term.

> Thanks,
>

Thank you!

> --
> Eric Lesage
>


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