On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote:
> Actually the scripts in $INSTANCE/bin aren't shell wrappers for things
> in $PREFIX/bin, they're shell wrappers for thing in
> $PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers.
And so they would be copied for all instance installed: they would not
probably be that large, but what about symbolik links?
> If you made a global control script that worked as per your example, how
> would you identify where the 'default' instance is?
I was not aware of a zopectl in the repository so i builded one in python for
Debian. As i can see it's quite more powerful than the one you are going to
I would care about any comment.
> FWIW, I'd be very opposed to any sort of limitations on where instance
> homes could be placed to service this global control script's need to
> find instances.
> dated Aug 22, 2002 8:09 pm for more background.
It's my opinion that a zope instance can be described trough a configuration
file, thus not requiring multiple commands or links but rather a single
command capable of using multiple configuration files. If you combine my
zopectl script with the patch is proposed for z2.py
(http://collector.zope.org/Zope/925), you'll have a good FHS compliant
framework for multiple INSTANCE_HOMEs (being still able to place any file
where you like).
> This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could
> libraries in the lib directory). This is why they're currently not
> broken apart.
To say it all there is only one thing i really need: a way to install _all_
documentation files under a separate directory in a way thay cannot overlap.
For what concern Debian, the intallation home will still be /usr/lib/zope
untill python fully comply FHS (http://python.org/sf/588756). I'll probably
move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure.
> In the past, my offers to provide upstream support for Debian packaging
> hasn't been met with much enthusiasm. If I can make it easier for
> people to package Zope for Debian, I'd love to, but I'd need to have
> some buyin and support from the current Debian packagers. Otherwise, it
> ends up being a waste of time on both of our parts as it won't be what's
> best for either of us.
It's not that easy to co-maintain the Debian package for Zope: we actually
lacks the structures to set up work with non Debian Developers. I suppose this
problem will be solved soon, but if you like i can start collecting patches
for the CVS repository i've already set up for that purpose.
Take a look at https://alioth.debian.org/projects/pkg-zope and its CVS
> Debian's packaging and installation strategy for Zope has always been
> very customized and divergent from the Zope source distribution's
> packaging and installation strategy. At very worst, it could stay this
Debian has choosed to be be strictly compliant to FHS, including it in the
Debian Packaing Policy. Not complying to Debian Policy is considered a grave
bug for any package in the distribution. Current Zope upstream package is not
that compliant, so we always have to modify the package. I hope this will
change in future.
Luca - De Whiskey's - De Vitis | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''. | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the language.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -