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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
