FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation

[Luca - De Whiskey's - De Vitis]

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.