Bugzilla Bug 41508

This is the request for ebuild for Zope-2.7.0 as it is now the latest STABLE
release.

Reproducible: Always
Steps to Reproduce:

*** Bug 32034 has been marked as a duplicate of this bug. ***

*** Bug 43802 has been marked as a duplicate of this bug. ***

Any news on this issue?

Created an attachment (id=28323) [edit]
zope-2.7.0 ebuild and related files

This is my first crack at an ebuild for 2.7.0. Due to changes to the way that
Zope 2.7 works (eg. no longer uses all those environment variables) and never
having used zope before :) I commented a lot of the old ebuild code for now.

It installs into /usr/lib/zope-2.7.0 as noted in Bug #31511.

I've included a patch to zopectl from the bug here:
http://zope.org/Collectors/Zope/1235

In the install_help() procedure, line 197, the proposed ebuild has

einfo "$ /usr/lib/${PV}/bin/mkzopeinstance.py"

I think this should be

einfo "$ /usr/lib/zope-${PV}/bin/mkzopeinstance.py"

Note that I've just prefaced the zope version with "zope-".

-Paul Komarek

The zope instance's var and log directories were created with user.group =
root.root.  This caused zope to fail after some time passed, or after someone
tried to connect (probably from trying to write a log or something).  One
symptom was a connection refused on port 8080, even though you could see zope
listening there using netstat.

Changing the user.group to zope.zope for these two directories worked.  For
concreteness: since my zope instance is in /var/zope, those directories are
/var/zope/log and /var/zope/var.

I followed the directions for running mkzopeinstance (as mentioned in my
previos comment, the path reported by the ebuild,
/usr/lib/2.7.0/bin/mkzopeinstance.py, was wrong -- that should be
/usr/lib/zope-2.7.0/...).  Should have run mkzopeinstance as user zope?  If so,
maybe the directions could include that.  If mkzopeinstance is supposed to take
care of perms.

Note that I'm not sure how mkzopeinstance could handle user/group stuff, since
the instance hasn't created yet.  Therefore $INSTANCE/etc/zope.cfg doesn't
exist, and the effective-user isn't set yet.  I think the ebuild should suggest
something more like:

 * To create a new Zope Instance use the following command:
 * $ su zope -c /usr/lib/2.7.0/bin/mkzopeinstance.py

However, I have not tried this myself (I just did chown zope.zope ...)

-Paul Komarek

I haven't figured out why yet, but the pcgi stuff from the Zope 2.7.0 tarball
is nowhere to be found after this ebuild runs.  That is, I had thought that
Zope-2.7.0/pcgi would be copied to /usr/lib/zope-2.7.0/pcgi, but it was not. 
Nor does epm -ql zope show the pcgi directory being installed.

As far as not installing stuff goes, there are many Zope directories that
aren't installed.  ZServer, utilities, etc.  Is there a reason for this?

-Paul Komarek

I caught the ${PV} typo also. It was actually supposed to be ${PF} which
resolves to zope-2.7.0 which is the same as doing zope-${PV}.

As for the ownership of the instance folders, I already patched
mkzopeinstance.py to use ZUID and ZGID (zope:zope) when creating the instance
folders. In install_help I say to run the command as a non-root user but root
may in fact be required for that command. 

Can you try creating a new instance as root (use /tmp/zope for instance path)
and see if it works? Due to how the script works you will still have ownership
of /tmp/zope but all files and folders inside it should be owned by zope:zope.

The pcgi directory in the source tarball appears to be empty. Maybe it's not
part of the core distribution anymore?

ZServer is installed here:
/usr/lib/zope/lib/python/ZServer

And utilities becomes /usr/lib/zope/bin

Note that /usr/lib/zope is just a symlink to /usr/lib/zope-2.7.0

I just learned that pcgi is deprecated for zope.  They are now suggesting using
a proxy, for instance mod_proxy with apache[2].  I'm learning how to do this.

-Paul Komarek

I tried creating a new instance as root using mkzopeinstance.py.  Whether or
not I set ZUID and ZGID, I everything under /tmp/zope/ was owned by root.  I
don't see anything in mkzopeinstance.py that refers to ZUID or ZGID; maybe your
patch wasn't applied for some reason?

-Paul Komarek

I just tried installing this ebuild, and I did not have zope installed before.
The ebuild failed when it tried to create a new user, so I changed the
pkg_setup function like this:

pkg_setup(){
    enewgroup ${ZGID}
    enewuser ${ZUID} 261 /bin/bash ${ZOPE_DIR} ${ZGID}
}

it seems ZS_DIR is no longer defined

I just tried to emerge the ebuild listed above - it doesnt seem to install any
init.d/ startup script.... am I doing something wrong?

Also, the help-text at the end of the ebuild process which tells the user where
to find mkzopeinstance and zopectl indicates an incorrect directory. 

It would be really great to get a working zope ebuild into Gentoo stable!

Created an attachment (id=30905) [edit]
patch for previous attachment's ebuild

Created an attachment (id=30906) [edit]
changes to zope-config to get zope-2.7.0+ to work.

Created an attachment (id=30907) [edit]
Simple change to /etc/zope-config.conf for zope-2.7.0+

Created an attachment (id=30909) [edit]
proposed replacement for net-zope/zope/files/2.7.0/zope.initd

Here's summary of my proposed changes:

zope-2.7.0.ebuild changes:
- fixed two bugs in unpack routine.
- added creation of .templates and population of zope.initd which becomes /etc/init.d/$ZOPE_INSTANCE
- added help for easy step after install assuming the zope-config changes work.
- included enewuser fix from previous bug comment

zope-config:
- added zserv_is_2.7_or_newer function to detect if selected zserver is 2.7.0+ or if it's an earlier version.
- added code to invoke mkzopeinstance.py if setting up 2.7.0 or later.
- added code to copy and customize /etc/init.d/$z_instance for 2.7.0 or later
- added ability to use zope-config --zpasswd for 2.7.0 or later

zope-config.conf
- added ZS_DIR2 which defines the new location for 2.7.0+ zope versions

net-zope/zope/files/2.7.0/zope.initd
- This one worked on my system! Somebody else give it a try :)

Created an attachment (id=30910) [edit]
proposed replacement for net-zope/zope/files/2.7.0/zope.initd

so when can we expect this in portage?

i'll take a look at the ebuilds over the next weekend. probably we can add them
to ~x86 afterwards.

any news on when it's gonna hit portage?

There is a small bug in the patched zope-config -- it should chown the newly
created /var/lib/zope directory to zope:zope, or the creation of subdirectories
will fail (for they are created under `su zope -c` command).

--- zope-config.orig 2004-06-02 19:38:46.790012184 +0800
+++ zope-config 2004-06-02 23:54:04.453373400 +0800
@@ -210,6 +210,7 @@

        if [ ! -d ${ZI_DIR} ] ; then
                mkdir -p ${ZI_DIR}
+               chown zope:zope ${ZI_DIR}
        fi

        while : ; do

We're 5 months late on this upgrade, what more needs to be done to get the
ebuild in portage?  We seem to have sufficient headcount of interested parties
to make this happen... 

I did some testing with the above ebuild (and patch) and found that I had to
add --ignore-largefile to the ./configure step in src_compile(). It seems that
Python on Gentoo is not compiled with large file support, or at least that's
what the configure script things. The test in Zope-2.7.0/inst/configure.py
looks like this:

def test_largefile():
    OK=0
    f = open(sys.argv[0], 'r')
    try:
        # 2**31 == 2147483648
        f.seek(2147483649L)
        f.close()
        OK=1
    except (IOError, OverflowError):
        f.close()
    if OK:
        return
    print (
        """
This Python interpreter does not have 'large file support' enabled. ...
"""
        )
    sys.exit(1)

I think this test is bogus. It is trying to itself by whatever name it was
invoked under, and I suspect this doesn't work very well. To test it
interactively, I changed sys.argv[0] to sys.executable (path to Python
interpreter) and it worked fine. It should be safe to add --ignore-largefile to
the configure options, although I really can't see where it is being enabled in
the ebuild.

Now I haven't tested the resulting build yet, because I haven't tackled the
zope-config issue which apparently exists.

Can someone (like maybe Carter, since he has done the most research on this)
put together a complete ebuild for 2.7.0, and maybe also a patchset and ebuild
for zope-config? 2.7.1_beta1 has been out for a couple weeks now and has a
bunch of fixes. This bug is also blocking (somewhat) bug #51825 (plone-2.0.3)
which recommends use of Zope-2.7.

Created an attachment (id=33521) [edit]
zope-2.7.1_beta2.ebuild

Here's an ebuild that I put together based on the 2.6.4-r1 ebuild. Summary of
changes:

 * Attempt to future-proof version number detection

 * Tarball naming convention has changed

 * ~arch for all platforms

 * Remove PYTHON_SLOT_VERSION testing due to python-2.3* dependency

 * Remove extraneous slashes in ZSERVDIR, ZINSTDIR

 * Minor indent fix in install_help()

 * Use new configure with --ignore-largefile due to bogus test (Gentoo python
has it, test thinks otherwise)

 * Remove all the .templates stuff since Zope now uses skel

 * Drop zope.confd because Zope has a etc/zope.conf now

 * Don't try to install a default instance; zope-config probably won't work
right without changes

To create a new instance without zope-config, use:

/usr/share/zope/zope-2.7.1_beta2/bin/mkzopeinstance.py \
  -d /var/lib/zope/zope-2_7_1_beta2 -u admin:password

To start Zope without zope.initd:

/var/lib/zope/zope-2_7_1_beta2/bin/runzope

zprod-manager works fine, as near as I can tell.

TODO:

 * Fix up zope-config

 * Rework/simplify zope.initd (Zope doesn't look at the environment variables
anymore). The one attached on this bug looks reasonably good.

2.7.1 is out. Since 2.7.1b2 was the last prerelease, and 2.7.1 only has one
bugfix in it, the 2.7.1_beta2 ebuild above ought to work fine. I'd update the
summary and URL but it won't let me.

2.7.1 broke my ebuild because it inexplicably changed it's source directory to
Zope-2.7.1-0 from the expected Zope-2.7.1. If you alter:

S="${WORKDIR}/Zope-${SFPV}"

to

S="${WORKDIR}/Zope-${SFPV}-0"

then it seems to work fine. I am reworking zope-config and doing more testing.

Created an attachment (id=33950) [edit]
zope-2.7.1.ebuild

Changes from 2.7.1_beta2 ebuild:

 * Fix ${S} due to unexpected source directory relocation

 * Set ZGID=zope; see discussion below

 * Remove some unused variables

 * Make setup_security() sane

 * Revise install_help()

 * Make zope user with zope group

 * Fix documentation

 * Fix speling erorrs in unicode patch section (don't know if this patch is
applicable any more, please test)

 * Remove rc-script editing (no longer needed)

 * Do NOT install a default instance; discussion below

 * Remove .default more simply

Security updates: Older ebuilds of zope (particularly 2.6.4-r1) go through the
extra step of creating a default instance with it's own group, and then
changing ownership of all the files to zope and the group to the default
instance's group, and removing all permissions from others. This is WRONG.
Instances run as the zope user; do you really want to zope user to own all the
files and have them writable? You sure wouldn't do this with apache, so why
Zope?

As a result, all the files in the ZSERVDIR (where zope is being installed) are
now owned by root and the zope group, which does not have write permission.
Others still have no read/write permission; I'm not really sure what the
rationale is for this, but it does not make it less secure.

Additionally, zope-config (patch to follow) installs it's instance files in a
similar way.

Created an attachment (id=33951) [edit]
files/2.7.1/zope.initd

This is the /etc/init.d/ script for the 2.7.1 ebuild. Put it in
net-zope/zope/files/2.7.1.

Created an attachment (id=33952) [edit]
patch for zope-config for zope-2.7 compatibility

Summary of changes:

 * Use a sane permissions scheme, but only for 2.7 right now; should probably
also be applied to earlier versions

 * Use mkzopeinstance.py to do the heavy lifting

 * For Zope-2.7, make the /etc/conf.d file on the file (hardly any parameters
needed now) and edit ${INSTANCE}/etc/zope.conf

 * Run zpasswd from the right place (2.7 has a bin directory)

 * Detect zope version by presence of bin directory

 * Don't try to add the instance group if it exists (suppress error message)

 * Update post-install instructions

Security updates: See also the discussion on comment #29. Previously (and still
for zope<2.7) the instance files were installed so that they were owned by the
zope user and the instance's group, and set to be owner- and group-writable,
and non-read-write by others This is WRONG. The instance runs as the zope user,
and most of those files should not be writable to the running instance. Now
they are owned by root and the instance's group, but not group-writable. The
exceptions are the var and log directories, which are group-writable with the
set-group-id bit.

If you are cc:ed on this bug, please test the ebuild and patch your zope-config
and report the results here. I've tested it all pretty thoroughly and I don't
think there are any issues, with one exception: I have not tested the
structured text unicode patch. I don't even know if it is applied or is needed,
since it is leftover from 2.6.4.

I'll also point out that the zproduct eclass has the same sort of file
ownership issue as the old ebuild and zope-config: When it installs files
(zproduct_pkg_postinst()), it chowns them zope:root. This of course makes them
writable by running zope instances. They ought to be root:root or root:zope.

zprod-manager seems okay in this respect, since it preserves permissions and
ownership of installed zproducts. 

I have tested Andy's latest ebuild along with the zope-config patch and they
seem
to work smoothly except for one minor issue: if you have a prior version of
Zope
installed (in my case zope-2.6.4-r1) the user zope already exists and is
assigned
gid 100. This prevents enewuser in zope-2.7.1.ebuild from assigning the correct
group (zope) to the zope user. As a result you cannot start your zope instance
"out of the box".
IMHO there is no clean solution to the problem. The 2.7.1 ebuild implements the
ideal behavior, but raises the above issue. A workaround might be to call
useradd 
with the -G zope option (maybe through enewuser), leaving the zope user with
users
(gid 100) as the default group.

Try changing the pkg_setup() section of the ebuild to this:

pkg_setup() {
    enewgroup ${ZGID} 261
    usermod -g ${ZGID} ${ZUID} 2>&1 >/dev/null || \
        enewuser ${ZUID} 261 /bin/bash ${ZS_DIR} ${ZGID}
}

That way if the zope user already exists, it will change it's primary group to zope, otherwise it will be added that way. I haven't tested this but it looks (more) correct.

zope.initd has a leftover echo ${PIDFILE}, which is debugging cruft and should
be removed.

Created an attachment (id=34055) [edit]
files/2.7.1/zope.initd

The old zope.initd wasn't too robust if zope had been killed: stop would fail,
even though zope was no longer running. Now it uses is_zope_dead, and if it is,
it doesn't try to stop it, and exits successfully.

Created an attachment (id=34059) [edit]
files/2.7.1/zope.initd

Sorry, I actually broke the common restart case where zope is actually running.
I think I've checked all the cases now and everything looks okay. I also found
a bug in is_zope_dead: A break statement caused a premature exit of the script.
This is in 2.6.4-r1 as well, I think.

Created an attachment (id=34078) [edit]
files/2.7.1/zope.initd

The code for determining whether or not zope was still alive was *still* buggy.
Since it was excessively complicated to start with, I threw out everything
related to is_zope_dead (including read_pid and check_pid_status) and wrote a
new zope_is_alive function. The init script is now about 25% the size of the
2.6.4 init script (reduced from 178 loc to 47).

Sorry for all the updates. Hopefully this will all get committed soon. Please
test this along with attachment #33950 [edit] and attachment #33952 [edit] and report your
results here.

OK, here's a relevant zproduct.eclass complaint: When you remove a package that
which inherits from zproduct, it also removes it from all of your zope
instances. It does this when you upgrade the package, too. When you install (or
upgrade), it only installs into the default instance. If you have more than one
instance, you're basically screwed, because only your default instance will
have it after an upgrade. And if it didn't have it before, it will now...

IMHO, the zproduct class:

1) Should not remove installed products from instances when unmerging the
package.

2) Should not try to automatically install products into instances.

3) Should SLOT all zproducts.

Re: slotting: /usr/share/zproduct has a directory for each installed zproduct
package. Inside that are the product directory(s) supplied by the package.
There would not be any conflict with having multiple versions of the same
zproduct installed, though only one version of each zproduct can be installed
in a given instance. This will probably require reworking zprod-manager a bit.

Perhaps the behavior of installing/removing zproducts from instances could be
controlled with an environment variable (set in /etc/make.conf), i.e.
ZPRODUCT_UPDATE, set to a list of all the instances to automatically update.

Also, I think having the default instance being determined by having a .default
file in it is a little weird. Why not have a symlink named default in the
/var/lib/zope directory to the default instance?

I am afraid that we're making the Gentoo zope install too complicated.  The way
things are going, we are likely to make all of the existing documentation on
Zope irrelevant to Gentoo users.  This would be unfortunate and create
confusion.

I think we should be careful and possibly reduce our ambitions.  I expect that
very few users care about having multiple instances, and a setting up a single
instance is easy (and can follow the bulk of extant docs).  Maybe we should
have two zope ebuilds, or otherwise have an option to make things "normal" or
"super-gentoo-ized"?  Please, someone help me, I'm almost ready to suggest
adding a use-flag for this!

Unless Gentoo plans to take over Zope maintenance, we will never control the
"usual" Zope install.  Unless we plan to support *every* Zope product in
existance, our strange super-gentoo-ized installs are likely to cause trouble.

The mitigating factor is that (probably) not many people install Zope.  But
they should!

-Paul Komarek

I agree that most people will not want to run more than one instance. One of
the problems with zope-config is that it sort of gives the impression that you
should create a new instance for each new version you install, since the
default instance name is "zope-".

I also don't think most people will want to have more than one version of Zope
installed at a time. However, you can't just upgrade a new version over an old
version, or automatically unmerge the old version, because you'll break the
running instance. This is why I argued previously (in some other bug) that we
needed to SLOT on the Zope version number: Update, change your instance config
to use the new version, restart, then unmerge your old version when convenient
(like if the new version didn't break something important).

If anything, with the zope-config patch and new ebuild I have on this bug,
configuration is less Gentoo-specific than before, because we're using the
mkzopeinstance.py that comes with Zope-2.7, which is what doc/INSTALL says to
use. Of course, nobody has to use the Gentoo tools; so long as we install
everything in reasonable locations, they can use the standard instructions.

In bug #31511 (opened by Paul), there's a good case for moving the installed
version of Zope, too, since architecture-dependent files should not be in
/usr/share. Most likely they'll move to /usr/lib/zope/${PV}.

Anyway, I think the zproduct install mechanism is trying to be too smart at
this point, and should leave instances alone. SLOTting zproducts would make
things a bit more complicated, but may be necessary in the long run: Some
zproducts require an upgrade procedure which we can't anticipate. Plone is the
most obvious example.

Bug opened 2004-02-13, now its 2004-07-11

5 months past, all other source distributions already have it, I really think its about time this was added, even if it has to be hard masked.

Agreed. I appreciate all of the hard work you guys have been putting into
making this ebuild work the way you want it to, but the time window is starting
to get very out of hand here.

I had to upgrade my zope site now, so I just gave it try today.
I used zope-2.7.1.ebuild, the patch for zope-config (and patched /usr/sbin/zope-config) and the latest zope.initd.
Basically it worked quite OK, but I had some (minor) issues with the permissions. I had to add the zope user manually to the zope group in /etc/groups and I had to change all the subdirectory and files in /var/lib/zope/zope-2.7.1 (INSTANCEHOME) to root:zope (they were owned by root:root and naturally that didn't work at all *g*).
After installing some zope products with the zprod-manager I had to change the permissions in /var/lib/zope/zope-2.7.1/Products/, but thats an issue of zprod-manager I think.
BTW: I want to go along with Hackeron and Davin and I think, this should be in portage ASAP now.
Last but not least: Thank you for your work with these fiddly stuff here. :-)

Created an attachment (id=35340) [edit]
fixed zope-config

OK, this is my zope config patched by both patches visible here.
it still contains some unnecesary (?) crud but correctly sets all permissions.
it just works (for me :) so you can create working zope instance.

i confirm that using zope-2.7.1.ebuild and my zope-config youre able to
sucessfulyy emerge zope and install instance without any errors.

there is one suggestions: you can change /usr/portage/eclass/zproduct.eclass,
there should be chown root:root instead of zope:root (only one chmod in file so
its easy to find). its not applicable to this bug, so i dont attach patch. this
causes all global versions of zope product being accessible for all users: zope
instances (for zprod-manager) and ordinary system users. i think its correct to
have 755 permissions on /usr/share/zproduct/* due to fact that not only zope
can use these files. if someone want to achive better protecion that should be
done in zprod-manager, still i dont think its good idea. i suggest leaving
/var/lib/zope/INSTANCE/Products/* as a 755 too.

well :) after a few month and really good work of you, zope2.7.1 and
zope-config made their way to portage. i was just able to do some quit testing,
probably there are some issues left. so i added them to package.mask
i don't dare to close the bug yet :) maybe next week?

Indeed, 2.7.2-rc1 is out as of yesterday (for a security fix), so let's give it
a couple of days.

btw, current ebuild should be fixed to allow any python 2.3.x (and propably
later).
current version has it as specific 2.3.3, so 2.3.4 causes [UD] flags on emerge.

Created an attachment (id=35399) [edit]
zope-2.7.2_rc1.ebuild.diff

This patch is against the 2.7.1 ebuild that is in portage.

 * Fix sub-version number, URI

 * Fix python dependency (python-2.3*)

 * Require zope-config-0.4 or newer

 * Set the ZS_DIR to /usr/lib/ as expected by new zope-config and be
FHS-compatible

 * Try to make user any existing zope user has the zope group as primary

BTW, zope-config looks ok, although there is a typo:

sed -i -e 's/uniqe/unique/' /usr/sbin/zope-config

One other possible minor issue: In previous testing, I found one product
(PloneCollectorNG) which, when you try to create the object within the ZMI,
dies because it cannot write to the instance's import directory. Currently this
is not one of the directories that is set to be writable, but I suspect that
PCNG is somewhat of an exception, and the error produced is quite explicit
about what needs to be changed, so I don't really consider it an issue,
especially since PCNG is not yet in portage that I'm aware of.

ok, here is my _proposal_, list of changes:
1. added pkg_config to ebuild to create default instance
2. info changes in ebuild (more einfo/ewarn)
3. changed SLOT to NOT include ${PR}
4. also changed /usr/lib/zope to not include ${PR}
5. added default instance management
6. added possibility to zope-config to create instance without user/pass ask

i attach zope-config and zope-2.7.2-rc1-r1.ebuild

Created an attachment (id=35770) [edit]
zope-config-0.4-r1

Created an attachment (id=35771) [edit]
zope-2.7.2_rc1-r1

2.7.2 is out.

Aside from spelling errors, attachment #35771 [edit] looks OK to me (I diffed against my zope-2.7.2_rc1.ebuild), but I haven't tried it out yet.

Created an attachment (id=35865) [edit]
newest zope 2.7.2  ebuild

spelling mistakes still present, but small fixes due to tgz name change on zope
has been applied to the ebuild.

please test it.

Being new to zope and familiar with portage only as a user, thanks for your
work!

I tried adding the attachment #35865 [edit] to /usr/portage/net-zope/zope as
zope-2.7.2.ebuild, replacing
/usr/portage/app-admin/zope-config/files/0.4/zope-config with attachment #35770 [edit]
and running 
emerge --nodeps -uv /usr/portage/net-zope/zope/zope-2.7.2.ebuild
/usr/portage/app-admin/zope-config/zope-config-0.4.ebuild
(nodeps because zope-2.7.2 requires inexisting zope-config-0.4-r1)

zope-config runs fine expect that it complains "install: cannot stat
`/usr/lib/zope-2.7.2/skel/zope.initd': No such file or directory".
Consequently,  in /etc/init.d/ there is no start script for zope-2_7_2.

Doing a "cp /usr/portage/net-zope/zope/files/2.7.1/zope.initd
/etc/init.d/zope-2_7_2" (for my zope-instance zope-2_7_2) and "chmod 755
/etc/init.d/zope-2_7_2" does the trick and zope seems to be running fine.

Using current zwiki-0.32.tgz inside /var/lib/zope/zope-2_7_2/Products works
fine (my inital intent to use Zope).

Warper, please put zope.initd into PORTAGE/net-zope/zope/files/2.7.2 directory
and emerging 2.7.2 ebuild (35865) will install into into skell directory,
making it ready for zope-config use.

i'm starting to integrate your fixes to portage. just a few things to mention:
please post patches/diffs, not entire ebuilds. e.g. 2.7.2 ebuild is not in sync
with 2.7.1....

integrated to portage

zope-2.7.2.ebuild : enewuser fails on completely new zope install

I neverd had installed zope on my gentoo box, thus emerge will install zope user and group. For the user, it tries to create a home directory, which fails.

ACCEPT_KEYWORDS="~x86" emerge zope 2>&1 | tee -a /tmp/emerge.log
gives me the following output excerpt (1st run / 2nd run)


 * Caching service dependencies...
 * Adding group 'zope' to your system ...
 *  - Groupid: 261
usermod: user zope does not exist
 * Adding user 'zope' to your system ...
 *  - Userid: 261
 *  - Shell: /bin/bash
 *  - Home: zope
 *  - Groups: (none)
useradd: invalid home directory `zope'

!!! ERROR: net-zope/zope-2.7.2 failed.
!!! Function enewuser, Line 641, Exitcode 3
!!! enewuser failed


2nd try -----------

usermod: user zope does not exist
 * Adding user 'zope' to your system ...
 *  - Userid: 261
 *  - Shell: /bin/bash
 *  - Home: zope
 *  - Groups: (none)
useradd: invalid home directory `zope'

!!! ERROR: net-zope/zope-2.7.2 failed.
!!! Function enewuser, Line 641, Exitcode 3
!!! enewuser failed

Toni, afaik its caused by removal of lines:
ZGID_INST="$(echo ${PN}-${PV} | sed -e 's/\./_/g' )"
ZS_DIR=${ROOT}/usr/lib/
ZI_DIR=${ROOT}/var/lib/zope/

from ebuild which went into portage.
it also can result in broken pkg_config. got to investigate it.

re-added :) now i know why you introduced these vars

I don't understand why it is that the new zope.initd was set up to require
zope-config doing a search/replace to set the path. It would have been much
simpler to use the $INSTANCE_HOME environment variable that comes automatically
from /etc/conf.d/<instancename>, particularly if that script ever needs to be
upgraded.

sed -i -e 's/INSTANCE_HOME/${INSTANCE_HOME}/g' zope.initd