zope2.10

[Martin Stadler]

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.

Martin