If you have PYTHON_SLOT_VERSION=VIRTUAL, and python-2.3* subsequently gets installed, Zope no longer works, and won't build. It does seem to work pretty well with python-2.2*, though, but the PYTHON_SLOT_VERSION support in the ebuild only considers "VIRTUAL" as a possible value. The following patch (to be attached) allows PYTHON_SLOT_VERSION to be assigned an actual version, i.e. "2.2", so that Zope can be merged using python-2.2.3 on systems that also have python-2.3.2 without having to install python-2.1.3. NOTICE: Simply bumping the revision number will clobber the existing installation's Data.fs, where is the primary site database, so don't do it. See bug #29705.
Created attachment 21943 [details, diff] Allow PYTHON_SLOT_VERSION to contain a version This patch allows PYTHON_SLOT_VERSION to contain a version number, or "VIRTUAL".
thx, added to -r1 :)
Unfortunately, the dependency checking for Python is getting hosed when you set RDEPEND=">=app-admin/zope-config-0.3". The following patch (to be attached) seems to fix it. (I think DEPEND was wrong too; python should be a build and runtime dependency.)
Created attachment 22111 [details, diff] Fix python dependencies * Add python to DEPEND * Don't nuke RDEPEND when adding zope-config
thx for pointing that out, zope-config is a depend as well as it is used within the ebuild, so i'll add it to depend
Shouldn't Zope be slotted? Currently the ebuild sets SLOT="0". This seems wrong, especially with it being installed into a path that includes the version number, i.e. /usr/share/zope/zope-2.6.2-r1.
SLOT is only if there are two or more versions that should be installed at the same time, i don't think you want to install two zope versions at the same time.
I understand slotting. However, the elaborate filesystem layout used by the current ebuild suggests that it was intended for slotting, i.e. /usr/share/zope/zope-2.6.2-r1, /var/lib/zope/zope-2_6_2. I believe that if you were set the SLOT to the version, you wouldn't break anything. Generally, though I would not want to have two different versions installed for very long, but I suspect it is necessary to be able to do a clean transition from one version to the next. Example: Zope-2.7.0 comes out and I am running 2.6.2 in production. I don't want my 2.6.2 tree nuked in the upgrade; it may fail in unpredictable ways. (Not Data.fs, that is safe now.) Worse, I might find out 2.7.0 breaks in some unanticipated way and now I have to remerge 2.6.2. I'd want to have SLOT=2.6 and SLOT=2.7 (*) and have then installed side-by-side for awhile, copy my Data.fs to /var/lib/zope/zope-2_7_0/var, run 2.7.0 on a different port so I can do some testing, and then switch things over when I'm convinced it's correct. Then I can unmerge 2.6.2 a few days later. (This should probably be tested in a non-production system first, but that isn't always feasible, or may not expose all problems.) (*): This works on the (mostly true and safe) assumption that 2.7.0-r1 or 2.7.1 will only have bugfixes over 2.7.0 and no feature changes.
