zope2.10

[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?


> 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.


> 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.