[Bug 631972] Review Request: plone3 - Plone CMS

bugzilla at redhat.com bugzilla at redhat.com
Thu Sep 9 19:13:45 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=631972

Julien Anguenot <julien at enfoldsystems.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien at enfoldsystems.com

--- Comment #7 from Julien Anguenot <julien at enfoldsystems.com> 2010-09-09 15:13:44 EDT ---
Hey Chen,

We have been working together on these RHEL RPMs with Nikolay.

Packaging each Zope and Plone egg dependencies as RPMs doesn't make sense for
us and we will not be interested in implementing, maintaining and deploying
something like that for our customers.

We believe this is not the right approach. At least for the Zope and Plone
dependencies.  We could discuss the case of Python low level component
dependencies for Zope and Plone though. (think lxml, twisted, zope.interface,
etc...) and even here I would have some serious concerns: see below.

We believe the Zope and Plone application level Python component dependencies
should be managed by buildout, only, without adding extra complexity at OS
level:

   http://pypi.python.org/pypi/zc.buildout/

Note, that not only our current RPM implementation supports buildout but it
allows one to extend and define its own custom application, the buildout way,
within another RPM, that would then be able to leverage the Plone base one in
term of core Plone version dependencies but as well as framework to build the
application and RPM (We have such examples of this already and are distributing
customer's packages this way very successfully)

In fact, let's say one would install both Zenoss and Plone on the same server
or a version of Plone3 and Plone4 (which is very common) : both application
would be using different Zope, Python dependencies etc... 

It would mean:

  1. Impossibility to install several Python based applications. Say we have
both a Plone3 and Plone4 instance using 2 different versions of the
zope.component egg (that according to your suggestion should be packaged as an
RPM) How would you deal with different RPMs of the same component at OS level
in this case? 

  2. Assuming we can work around #1, we are talking about a lot of RPMs here.
Say you have both Plone3 and Plone4 installed it means you would reach
approximately 500 RPMs. (a significant percentage if the overall system's RPMs
just for 2 Python applications)

Just to make sure we are talking about the same thing here:

Plone4 egg dependencies:

   http://dist.plone.org/release/4.0/versions.cfg

Plone3 egg dependencies:

   http://dist.plone.org/release/3.3.5/versions.cfg

Zope 2.12.10 egg dependencies:

   http://download.zope.org/Zope2/index/2.12.7/versions.cfg

For instance, why would I maintain an RPM for 'plone.app.redirector egg'
outside of the Plone one when this one only makes sense inside the Plone
framework?

To sum up:

  1. We don't believe it makes sense to package hundreds of application level
eggs as RPMs

  2. Having one RPM for Zope and having the Plone RPM defining it as a
dependency would be something we could discuss (although, we think it doesn't
add value but complexity for something not obviously beneficial.)

  3. Please tell us if having an RPM for an egg is really compulsory. If so,
then it will be a deal killer for us and we will not move forward with this on
our side.

Let me know if you have any questions or if I am missing something obvious
here.

Thank you.

  J.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list