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@xxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julien@xxxxxxxxxxxxxxxxx --- Comment #7 from Julien Anguenot <julien@xxxxxxxxxxxxxxxxx> 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review