The current zope ebuild puts several shared objects into /usr/share. For example, Acquisition.so, BTree.so and ComputedAttribute.so are in /usr/share/zope/zope-2.6.1/lib/python. Not only does this violate the LSB (which defers to the FHS 2.2 on this), but it's just plain stupid. Of course the zope scripts are hanging out there, too. While they're less likely to be arch-specific, they can be. Besides, those scripts programs -- they are more like /usr/bin/mozilla than like /usr/share/rfc/rfc-index.txt. There must be some bin, lib or libexec directory that the zope application could call home. What's next? Network binaries in /etc? ;-) -Paul Komarek
any constructive suggestions? the current setup puts the shared files to /usr/share/zope/zope-xyz when you create an instance, the instance files are in /var/lib/zope/zope-instance where would you put the ZOPE home and where the INSTANCE home? the zope 2.7 ebuilds need to be done, if the current ebuilds really violate FHS, we should work on this. the bug is quite old..., but i think it is still sth. to think about.
Maybe /usr/lib is a better place for the libs, otherwise /opt. In fact, I wouldn't mind at all if the zope ebuild just grabbed the zope tarball, unpacked it in /opt, and made a nice initscript for me. It would also be nifty if the config action could set up pcgi for me. I really can't say I have a use for more than one zope on my system, but I don't know about anyone else. For that reason the zope ebuild has always been a bit of overkill for me.
i vote for /usr/lib as well
that's where debian puts the files as well (http://packages.debian.org/cgi-bin/search_contents.pl?page=1&word=zope&version=testing&arch=i386&case=insensitive&searchmode=filelist) maybe we should also consider to switch from zope-config to zopectl for zope-2.7 (http://packages.debian.org/testing/admin/zopectl)
i think it's a must to use the new zopectl provided with zope. it's very good, but it's some work to adapt the things to gentoo,.. and usr/lib is also fine... another thing to think about in future: zpackage and pip. this makes all the filesystem ebuilds for the zope products unnecessary, as zope itself can fetch the products from an online repository and install them into his own products directory.
Posted an initial ebiuld for 2.7.0 to Bug #41508.
/usr/lib/${P} sounds good to me, although this would require things like zope-config and zprod-manager to do some filename globbing. How about /usr/lib/zope/${P} or /usr/lib/zope/${PV}? (zope uses SLOT=${PV})
o.k., i'm integrating the zope 2.7.2 ebuild to portage, will move to /usr/lib/zope-${PV}
>=net-zope/zope-2.7.1 puts files in /usr/lib/zope-${PV}, instances are still in /var/lib/zope/zope-instancename
