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="[EMAIL PROTECTED]" | don't depend on the language. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
