Martin Stadler martin at siarp.de
Sun Feb 1 13:42:03 PST 2009

Am 17.01.2009 um 02:17 schrieb Ryan Schmidt:

> Hi Martin. Thanks for your interest in Zope! It looks like the port  
> hasn't been updated in some time and it could use some attention  
> from someone such as yourself with an interest in the software.
> On Jan 15, 2009, at 15:51, Martin Stadler wrote:
>> I'd like to have a zope2.10 port.
>> There's a "zope" port which is currently at version 2.8.7. I think  
>> it would be reasonable to have multiple Zope ports like 2.9, 2.10,  
>> 2.11 etc. as it is the case with the Python ports for instance.
> The reasons why we typically have multiple versioned ports are  
> because of incompatibilities between those versions of the software.  
> For example, Apache modules are different for Apache 1.x, 2.0.x and  
> 2.2.x, so we have ports apache (1.x), apache20 (2.0.x) and apache2  
> (2.2.x). Python modules build differently for different versions, so  
> we have ports python21, python22, python23, python24, python25,  
> python26, and python30, and every individual Python module port must  
> also be duplicated, e.g. py-setuptools (for 2.4), py25-setuptools  
> (for 2.5) and py26-setuptools (for 2.6).
> There are also ports for databases like PostgreSQL and MySQL that  
> are available in different versions, because the user must convert  
> their database data from one version to another, and we want the  
> user to be free to do that conversion at a time of their choosing,  
> after they've made sufficient backups of their data, and not have it  
> forced on them by "port upgrade outdated".
> And then we also have ports that exist just to be used as  
> dependencies. For example, we have the autoconf port which provides  
> the current version 2.63, but PHP requires the much older autoconf  
> 2.13, so we have the autoconf213 port just for that.
> This strategy should be the exception and not the rule. Most ports  
> should just exist once in the tree and be updated to the latest  
> version.
> Do any of the above scenarios apply to Zope?

Zope itself in its different versions is a dependency for web apps  
like Plone or custom apps so yes, I'd say your first two points apply  
and there should be these separate ports.

>> I had a look at the current Zope port and it also creates Zope  
>> instance. Linux distributions like Debian have a separate package  
>> called zope2.10-sandbox or zope2.9-instance or so. I like this  
>> concept more since I personally don't need a prepared instance.
> I don't know Zope so I don't know what's appropriate. MacPorts  
> usually offers ports that are full-featured if possible. But if the  
> prepared instance is a large entity, or requires additional  
> downloads, or lots of time to compile, and users will likely want to  
> omit it, then MacPorts should offer that option. One way to do that  
> would be with variants, but I like multiple smaller ports, as you  
> suggest, better, because you can't declare dependencies on variants  
> of a port, and it's more trouble to reinstall a port with additional  
> variants than it is to just install another port with the additional  
> features.

Yes,  multiple ports.

>> The existing Zope port installs Zope into ${prefix}/libexec, Debian  
>> in /usr/lib. I don't know much about Unix directory structure  
>> conventions so I can't tell what fits better.
> According to "man porthier", ${prefix}/lib is for libraries --  
> generally dynamic libraries (.dylib), static libraries (.a) and  
> libtool files (.la) -- while ${prefix}/libexec is for executable  
> programs that the user is not meant to execute directly, but which  
> are instead executed by some other process.

So it sounds like a good fit.

I was hoping for some Zope users to join the discussion. I personally  
don't feel that I could maintain the port. The version I posted works  
fine for me with my Plone buildouts. Would be nice to have it in the  
tree but it's not too hard to add it locally.


More information about the macports-users mailing list