The package is not intended to be used on the stable distribution as you are doing, that's why you are having a painly install experience, it's not a package/age problem.

First of all, I don't think it's a good idea to have a stable/etch-backport/testing system mix.
Some openacs dependencies, like tdom 0.8.3, need a version of the libc6 more recent than the etch version, so you'll have a testing system even if you want it or not.

Also, this configuration has the problem of having to increase the size of apt cache to contain all the packages of the three repositories. I bet that the TCLLIBPATH problem is related to that config too, I have never seen it on lenny installations.

Finally, there is no need to add the compatibility options on postgresql.conf, the installer sets this options directly on the openacs database.

Cheers,
Héctor Romojaro

The decision to choose one debian version that supports the packages we need is the correct one.

> "[...] Beware, our packaging activity explicitly targets
> Debian GNU/Linux unstable ("sid") [...]"

Good point, I read over this.

And (I've said that this is the first time I'm really starting with Debian, didn't I?) I had no idea that I was setting up a "mixed" system.

And just taking this "novice" route - could somebody please point me to a place where I can download a suitable "sid" cdroom image? I've check the www.debian.org now for at least 10 minutes and didn't find anything...

I think that this would also be a wonderful extension for your http://openacs.com/xowiki/debian page...

Keep up the good work and thanks for the patience guys!
Frank

And just taking this "novice" route - could somebody please point me to a place where I can download a suitable "sid" cdroom image? I've check the www.debian.org now for at least 10 minutes and didn't find anything...

There are no distribution images for the unstable/"sid" branch, see http://www.debian.org/CD/faq/#unstable-images.

You have to get a testing/"lenny" installation (released daily and is checked for its soundness and installability), see http://www.debian.org/devel/debian-installer/. Select the appropriate "netinst" platform variant, then proceed with a raw installation. Then:

1. update your sources.list for the deb package manager (basically substituting "testing" occurrences for "unstable").

2. call "apt-get dist-upgrade"

3. your system will upgrade and will so track unstable

However, for production use, Dave Bauer's hint at the ubuntu server installation (preferably the long-time support LTS version 8.04) is the way to go: you get the advantage of an assembled and checked debian unstable, our packages, and security fixes through 2013.

//stefan

At this point, the persons involved on the debian/ubuntu openacs/dotlrn packages are Stefan Sobernig, Avni Khatri, Carl Blesius and me, and we are mantaining the following packages:

- xotcl packages (now on debian testing/sid and ubuntu intrepid/jaunty)
- tdom 0.8.3 (now on debian testing/sid and ubuntu jaunty)
- openacs (waiting for revision of the debian tcl/tk team)
- dotlrn (waiting for revision of the debian tcl/tk team)

Debian testing is freeze right now (since 27 Jul), and is expected to be released in a *short* period of time. Once it's released, there will be no problem on installing the openacs and ubuntu packages, because the dependencies will be on stable.

After that, debian people will revise the openacs/dotlrn packages, and they will get into the next debian stable release (I hope so!).

Meanwhile, it's possible to build a backport of the packages (xotcl-*, tdom, openacs and dotlrn). If the dependencies are backported, I can backport openacs and dotlrn packages easily, but I'd like to know other's people opinion, specially Stefan's, about that.

Also, you should take into account if it's worth to build the backport before lenny is released...

Cheers, Héctor

Thanks for your expression of interest. Even if later, this is highly welcomed by those involved.

I can only second Héctor's statements: Going for a concerted backporting initiative for the current debian stable ("etch") *now* would not pay off in the mid run.

Waiting for lenny to become the stable distribution and then setting up backports of upcoming packages versions from unstable is certainly a valuable contribution.

In the meantime, you can use the current testing distribution for your server installations. All openacs|dotlrn dependencies are in there (by now). Backporting openacs|dotlrn packages themselves should be a relative ease.

As for the "package building environment", you can freely use the package sources for setting up your playing ground:

1. see http://openacs.org/xowiki/debian, follow the package links to the Debian Package Tracking System (PTS). There, links to the SVN repositories are given. You can use the Debian "svn-buildpackage" facilities to get the sources, mangle them, and build binaries and distribution packs therefrom.

2. the openacs|dotlrn packages are managed at http://cvs.openacs.org/cvs/installers/debian/. Here, go for "cvs-buildpackage". Once approved by the Debian Tcl/Tk Team, they will certainly move to the Debian SVN.

I am always happy to help out, once you decide to get started.

//stefan

http://www.debian.org/News/2009/20090214

//s

I'm testing http://www.project-open.org/download/install-debian.html and I've found a problem:

apt-get install openacs
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
No se pudieron instalar algunos paquetes. Esto puede significar que
usted pidió una situación imposible o, si está usando la distribución
inestable, que algunos paquetes necesarios no han sido creados o han
sido movidos fuera de Incoming.
La siguiente información puede ayudar a resolver la situación:

Los siguientes paquetes tienen dependencias incumplidas:
  openacs: Depende: aolserver4-nscache pero no es instalable
E: Paquetes rotos

I've just updated the packages on the sid repository, removing the aolserver4-nscache dependency, which is now integrated into the aolserver4-core package (thanks Stefan for pointing it out ).

Cheers, Héctor

in your config file, because the nscache module is not needed anymore ( there is a built-in version of ns_cache ).