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

[Mike Rylander]

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

Thanks, and no problem, I was just interested in what needs to be
fixed.  We use local boostrapping SQL specific to PINES, so I'm not
surprised that the embedded stuff has some bit rot going on.  With the
SC having problems, we definitely need to get some working baseline
data in there, as well as have the SC protect itself better in those
situations.

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

Oh, definitely --  I didn't mean to give the impression that we aren't
interested in bugs, I just felt an explanation of how those came to be
was in order.  I've fixed the permission.grp_tree baseline values on
the rel_1_0 branch based on your statements above.  The base group
permission set is incomplete, but I don't have time right now to build
a better set.

[snip]

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

Don't we know it :P ... "Crazy" here means things, like MARC::Record,
that haven't been released (BTW, if the old release worked properly in
modern perls then we'd just stick with it) and packages where the
author seems to go a little insane (and API-change-happy) right after
you invest heavily in his tool (Class::DBI).  Hopefully /those/ types
of crazy will be limited overall.

> been updated by my latest emerge, maybe something broke and I don't know
> it yet :)

I guess we'll see! :)

[snip]

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

It doesn't, but that could simplify things later on.  Of course, until
we have an automated build/packaging setup, it's just one more thing
to forget (and break) during each release.

We should give a good bit of thought to this, though.  Ideas? (field,
table, schema level versioning, etc...)

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

See, now ... you gotta go tryin' to start fights ... ;)

> --
> Eric Lesage
>


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