[Zope-Coders] Re: Making Zope2 more LFH compatible

[Christian Heimes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris McDonough wrote:
| That said, were you to say that "the result of installing Zope from the
| current 2.6 binary release available on Zope.org is not LFS compatible",
| I'd imagine this would be true.

Acknowledged! Your way to express the issue points to the truth.

| Given this, hopefully we can make it possible to use the source
| installer to generate a filesystem layout that more or less complies
| with any given hierarchy standard.  It is basically just a matter of
| offering install-time file-location options.

Yeah! For now there are very less options to define, where different
parts of zope should be installed. We should tune up the new (and great)
distutils configuration and installation scripts to make it possible to
split zope in different parts. This *should* be an alternative to the
way zope cvs head is installed now because some people hate it when zope
is splattered all over the filesystem like after a hughe helter-skelter.

| Note that Zope3 does take the tact of rooting everything in a 'zope'
| package namespace as you suggest above.  It's a bit too late for Zope2
| to do that.

Oh, your right. I missed this although I'm a zope3 contributor. *damn*

| If people want to install the libraries that come with a particular Zope
| release directly into site-packages (e.g. site-packages/Acquisition.so,
| site-packages/AccessControl, etc), I see no reason to stop them,
| however, and I think the source install should make that possible (but
| not the default).

Do you have any ideas how to do this? I symlink can produce failurs and
a copy of the files is not very beautiful.

|>/var/log/zope/$INSTANCE_NAME/ - zope logs
|
| This can be specified in the Zope config file for each different Zope
| log file.  (eventlog/path, access/path, trace/path).

Yes, but there is no var for the $INSTANCE_NAME, only for the path to
the $INSTANCE. With a %define INSTANCE_NAME myinstance people could use
this var for e.g. /var/run/zope/$INSTANCE_NAME/Z2.pid.

| To help binary distribution creators, mkzopeinstance probably needs to
| make it easier to place instance files in separate directories and needs
| to generate a zope.conf that reflects logfile/lockfile/pidfile placement
| options that can be fed on the command line.

There should be command line arguments for
* pidfile
* logfile
* lockfile
* effective user and effective group under that zope is running, so
directories and files (log, pid, import ...) could be chowned to this
user.group
* conf
* instance name and a way an instance name macro could be used in the
command line

example
$ mkzopeinstance --instance-name main --uid zope --gid zope --pid-file
/var/run/zope/%INSTANCE_NAME%/Z2.pid --conf-file
/etc/zope/%INSTANCE_NAME%.conf --lock-file
/var/lock/zope/%INSTANCE_NAME%/Z2.lck /var/lib/zope/%INSTANCE_NAME%

AFAIK %INSTANCE_NAME% is not expanded by a unix shell so it could be
recognized by the script.

|>/etc/zope/__default__.conf - default configuration which could be
|>overwritten by /etc/zope/$INSTANCE_NAME.conf
|
| I'm afraid I don't understand what this is for, but it sounds like
| something that would be used in a framework like Luca DeVita's debian
| zopectl (e.g. it would not be a part of the Zope source install).

My idea was to have a config file with no macro expansion which could be
included in other config files.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1-nr1 (Windows 2000)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+8w5y9aLWrfOU0PgRAshcAJ90ErG4qruek/i+71yoCvD95Kzy0QCgtPVv
3IpxyIRCUkk25oSP9JXtKo0=
=PDb5
-----END PGP SIGNATURE-----