[kobold at debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]

[Jonas Meurer]

hey again,

On 20/09/2009 Matthias Klose wrote:
> The zope2.12 release candidate was released last week. I updated the
> packaging in the zope team repository. An upload still requires some
> work, because some modules still need to be packaged. These are:

zope2.12.0 final was released some days ago, and i uploaded packaging
accordingly. unfortunately the zope2.12 packages are far from building
succuessfully ...

>   Acquisition DateTime ExtensionClass
>   Persistence RestrictedPython tempstorage zLOG zope.container
>   zope.contentprovider zope.contenttype zope.deferredimport zope.formlib
>   zope.lifecycleevent zope.pagetemplate zope.processlifetime zope.sendmail
>   zope.sequencesort zope.site zope.size zope.structuredtext zope.tal
>   zope.tales zope.testbrowser [zope-functional-testing] (UNRELEASED?)
>   zope.viewlet zope.app.form zope.app.publication zope.app.publisher
>   zope.app.schema
> 
> All other zope dependencies are available as modular zope packages
> in unstable. Please have a look how these are packaged, and start
> packaging. As an interim solution it could be useful to include the
> still missing modules in the zope2.12 package until all these are
> packaged.

as mentioned earlier, the upstream build system (buildout) doesn't
accept other versions than given in versions.cfg for dependencies. this
is different for zope3, but for zope2.12 they seem to keep strict
versioned dependencies. you may be able to build zope2.12 with
dependency versions different from versions.cfg by building in another
way than recommended upstream, but future versions of the dependencies
might break compability, and at that time we're lost and left alone.

thus i would like to build zope2.12 packages the recommended way where
possible. that means to ship python/zope eggs within the zope2.12
package and use download-cache + install-from-cache in buildout.cfg

the current debian/rules from zope2.12 packaging still uses the old and
obsolete autotools build process. this is depreciated and not supported
any longer with the release of zope2.12. i guess it's only included into
the zope2.12 tarballs by mistake and might be removed with a subsequent
release.

thus we need to migrate our debian/rules to build zope2.12 with the help
of buildout, whether we like it or not. unfortunately buildout seems to
be a real pain for building distribution packages. it hardcodes absolute
pathnames into scripts everywhere, etc.

i didn't manage to roll a sufficient buildout.cfg for zope2.12 debian
packages yet, and would really like to discuss this with you before
commiting any further changes to the zope2.12 packaging repository.

following is a list of thoughts and problems i ran into:

- we have to ship copies of dependency eggs within a cache dir inside
  the source tarball.
- this egg-cache can be used by adding download-cache and
  install-from-cache options into buildout.cfg
- all eggs are installed into eggs/ subdir by default. i don't like the
  idea of installing this subdir within the zope2.12 package, but don't
  see another solution either yet. (/usr/lib/zope2.12/python/eggs)?
- absolut pathnames are hardcoded into bin/runzope, bin/zopepy, etc.

finally i get the feeling that building FHS and debian policy compliant
zope2.12 is a real challenge with the new build system. maybe someone
with better python/zope/buildout skills could give advice ;-)

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-zope-developers/attachments/20091004/06ba5643/attachment.pgp>