[Pkg-zope-developers] zope 2.7 questions

[Doug Winter]

On Thu 22 Apr A Mennucc wrote:
> 1) my wish would be to build a package by the name zope2.7 
>  that installs into  /usr/lib/zope2.7 /var/lib/zope2.7
> 
>  There is a good reason for this: zope 2.7  is not considered 
>  yet stable enough by people doing commercial work (I was told by friends
>  working in such a company); so I would not replace the package 'zope'
>  that is now in Debian with a 'zope' of version 2.7

I would agree with this, though for a different reason - Zope, or at
least many of it's products, are rather brittle and intolerant to
change.  It's quite likely that later versions of Zope will require
different configuration, or won't work with existing products perfectly.

If you can't upgrade automatically and reliably, you really need new
package names.
 
>  1b)  A better solution would be to change the products: 
>  we may add into the zope-policy this idea:
>  "any product that works with any version of zope available in Debian
>   (possibly by autodetecting needed changes)
>   installs into   /usr/lib/zope 
>   Otherwise it should install into /usr/lib/zope2.6 or /usr/lib/zope2.7 "
> 
>  Them we  change 'zope' to install into  /usr/lib/zope2.6 
>  
>   zope 2.6 would have  PYTHONPATH=/usr/lib/zope2.6:/usr/lib/zope
> 
>   zope 2.7 would have  PYTHONPATH=/usr/lib/zope2.7:/usr/lib/zope
> 
>   We may even have a virtual package 'zope' and have packages 
>   'zope2.6' and 'zope2.7' 
> 
>   I like this idea best: for example, we may have both plone1 and plone2
>   in Debian

Agreed.  Package names for zope products should probably be like:

    zope2.7-plone2
    zope2.7-plone1

etc.

> 2) zope 2.7  eases up a lot   creation and management of multiple instances, 
>   (and my package contains an extra script to help admins)
> 
>   this instances are quite cool.... but are not FHS compliant:
>   any instance contains its own 'etc' 'var' 'bin' and 'log'
> 
>   I would not move 'bin' which contains bin/runzope bin/zopectl
>   that start/stop that particular instance; and similarly 'etc'
> 
>   'var' can stay where it is
> 
>   maybe it is possible to move away 'log': for example
>   we may move  /var/lib/zope/instance/XXX/log   to
>   /var/log/zope/XXX
> 
>   what do  you think?

An additional issue is ZEO.  Using ZEO is a must for any decent-sized
zope installation, and I think we should plan for this too.

We configure our Zope and ZEO installations using m4 macros to build all
of the appropriate files required: zope.conf, zeo.conf, runzeo, zeoctl,
runzope, zopectl, init.d scripts and storage configuration for dbtab.

Perhaps something similar to the exim4 maintainer's approach would be
useful, where new instances can be built easily based on our own
configuration file format, using standard boilerplate templates.

I'm happy to help with this - I have a lot of this in production
already with 2.7.

>  I personally don't think that making zope FHS-compliant
>  is worth the effort... it would break too many things!
>   and you?

IMHO I think it has to be, to be honest, although it is effort.  I
currently run a moderately large zope installation with my own debs of
zope 2.7 and the products I use.  I haven't made it FHS compliant (i
just put everything under /usr/local/zope2 right now), and I haven't
made the instance structure FHS compliant either (stuff goes in
/usr/local/zopeinstanceNN/etc /var /data etc.)

This is now causing me problems with disk space, cache file location and
so forth.  An FHS compliant structure would solve all of these problems
(and would not surprise people).

If users wish to create their own instances of the normal format, we
can provide the tools for it - but I think we should go with the FHS by
default.

doug.


-- 
   http://adju.st   | "I have never predicted anything, and I
6973E2CF: 2C95 66AD | never will".
1596 37D2 41FC 609F |     -- Paul Gascoigne
76C0 A4EC 6973 E2CF |