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 include: http://packages.debian.org/unstable/admin/zopectl.html 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. [...] http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration 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[1] 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[1] (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 repository.
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 way.
Debian has choosed to be be strictly compliant to FHS[1], 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. ciao, [1] http://www.pathname.com/fhs/ -- 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="it_IT@euro" | don't depend on the language.