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

[Eric Lesage]

On Mon, 8 Jan 2007, Mike Rylander wrote:

> On 1/8/07, Eric Lesage <lesagee at iro.umontreal.ca> wrote:
>
>> 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).

Well that's what I meant by "debug application.ini". Sorry I wasn't more 
clear.

>> - It's not obvious to have the system run under a non-superuser in
>> PostgreSQL. [...]
>
> 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.

True enough. For myself I do it such that if there is ever a data lossage 
bug, the impact is limited.

>> - 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?

The statements lacked the value for the column which indicated if users 
could be added to the group the row represents. Also the order of columns 
for the System administrators row was not correct. I'm sorry if I'm being 
unclear, I don't have this in front of me at this time.

> 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.

Fair enough. But the staff client chokes on this too, when it receives a 
null reply from the server. Are you actually interested in bug reports 
for releases (non-CVS)?

> 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.

There's also a plethora of .pl scripts that seem to be there for utility 
functions such as importing data... I'll have to check them out.

> 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.

Ok, I'll give this a look.

> 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.  ;-)

Dependencies have a way of evolving... in fact a lot of perl modules have 
been updated by my latest emerge, maybe something broke and I don't know 
it yet :)

> 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).

If I get some time I'll do some ebuilds that fetch directly from CVS 
(including CVS dependencies). It should keep the my tarball leaner. On the 
other hand, if someone has a bug, it won't be as easy to reproduce.

> 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.

Does the database record the version of the schema somewhere? I guess that 
could be useful.

Hmm... looking forward to FRBR? (joking ;-)

-- 
Eric Lesage