Forum OpenACS Development: HEAD problem with package repository installer

ok, so here's the scenario:

* all works fine on one box
* the box in question bootstraps the core installer fine
* the box in question APPEARS to install the package ok (albeit extremely quickly)
* but it doesn't source any of the sql files (and i am not sure if it is sourcing the post-install tcl)

the key difference is: on the box with the problem, postgres is running on port 5433 and in /usr/local/pgsql734

i have the LD_LIBRARY_PATH and PATH set to point there, and (redundantly) the port set in the db pools in config.tcl

the site works fine with the installed core packages, in fact if i manually change, for example, edit-this-page.info to indicate initial install, then it is installed and functions fine.

so there is something not right in the functions used by the new package installer when sourcing sql files - possibly to do with the db port.

my initial inspections have shown nothing, and db_get_port returns the correct info (as does db_get_pgbin).

I am really tearing my hair out here! And i really want 5.0 on this box for a production server (i know, beta is beta...), and i want to use pg 7.3 (7.2 is running on port 5432).

gee - i want a lot don't i!

Collapse
Posted by Mark Aufflick on
furthermore, if i use the old-style apm installer it works fine (it seems to use the same psql based sql load proc that the bootstrap installer uses).
Collapse
Posted by Lars Pind on
Mark,

This sounds serious. Can you be a bit more explicit, please.

Let's focus on the box that's having problems ...

1) You install OpenACS using the bootstrap-installer

2) You visit /acs-admin/install and installs from local file system .. which packages?

3) The SQL files do not get sourced.

Is that the scenario?

I'm fairly confident it doesn't have anything to do with the PG port. We routinely have PG running on different ports.

But I did experience a problem with the new installer not sourcing DB files right, because the paths wasn't constructed just right. But I fixed what I found.

Are you 100% up-to-date on the code?

/Lars

Collapse
Posted by Mark Aufflick on
nearly - the only time it worked was when i had a package in the local file system and used the old installer (/acs-admin/apm/packages-install). Using the new installer, the packages get downloaded correctly, but the DB files are not sourced whether the package is already in the file system or not.

Running QDDebug and postgresql in full debug has yielded no info, so nothing seems to be hitting (or attempting to hit) the db connection pools.

It could be a filesystem location since I am not following the standard /web convention on that server, and the server that works is.

I was 100% up to date on both servers when I ran the tests yesterday (I double checked) and a quick check of the core packages shows no cvs diffs since then.

Collapse
Posted by Lars Pind on
Hm.

I just found and fixed a problem when upgrading packages. We tried to upgrade from the current package's version_id (object_id), not the version_name ("5.0d3"), which caused upgrade scripts to not be found at all.

But you're talking fresh install, right?

In order to troubleshoot this, I've added a debug log statement to install-3. Could you please try and get this, and turn on debugging (or just manually change it to Notice), and let me know what it says?

Also get any other upgrades, just in case.

Thanks for taking the time to help track it down.

/Lars

Collapse
Posted by Mark Aufflick on
ok - that yields:

[17/Oct/2003:01:09:36][24062.81926][-conn2-] Debug: Data model scripts: 
upgrade_from_version_name = 
upgrade_to_version_name=4.5
package_path=/home/agiweb/openacs-4/apm-workspace/install/page
package_key=page
 => 
[17/Oct/200...
ie. $data_model_files is blank ...

checking pagages/page/sql/postgresql shows the correct files have been copied over, so i guess the package path above is correct (the /home/agiweb/openacs-4/apm-workspace/install/ part is - but i have not intercepted the install script part way)

so it looks liek apm_install_packages is never getting the files to load... just about to turn on APMDebug...

Collapse
Posted by Mark Aufflick on
ok - all fixed now.

thanks for your verifying help peter