Bug 631972

* The package 'plone', though retired, has already been in Fedora. You should request for surviving that package instead of submitting the same package with a different name.

Refer to: https://admin.fedoraproject.org/pkgdb/acls/name/plone

* You should submit the latest version of that package for review. The latest version of Plone is 4.0.

Refer to: http://pypi.python.org/pypi/Plone/

* If you are sponsored, you may help updating Plone for epel5, which needs Plone 3.

Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=497933

* Will you join the Zope SIG? We are a little group trying to package all Zope programs, including Zope2, Plone, Grok, BlueBream, etc., for Fedora.

Refer to: https://fedoraproject.org/wiki/SIGs/Zope

Packging plone is not an easy task, we still wait for the final release of zope 2.13 which is compatible with python 2.7.

(In reply to comment #1)
> * The package 'plone', though retired, has already been in Fedora. You should
> request for surviving that package instead of submitting the same package with
> a different name.
> 
> Refer to: https://admin.fedoraproject.org/pkgdb/acls/name/plone

i think Plone 3 should have separate rpm because in many cases exact version of plone is required. for most of our customers we are still using plone 3. also i don't think split zope and plone is a good idea, each plone version require exact zope version and python packages. 

> * You should submit the latest version of that package for review. The latest
> version of Plone is 4.0.
> 
> Refer to: http://pypi.python.org/pypi/Plone/

we are willing to make plone4 rpm as well.
 
> * If you are sponsored, you may help updating Plone for epel5, which needs
> Plone 3.
> 
> Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=497933
> 

i can rename plone3 rpm to plone. but in any case plone 4 should have different rpm name.

(In reply to comment #2)
> Packging plone is not an easy task, we still wait for the final release of zope
> 2.13 which is compatible with python 2.7.

i don't think using zope rpm for plone is good idea.

Bundling several projects in one rpm is strictly forbidden by Fedora[1] and many other linux distributions like debian, gentoo. You should package every python egg seperately to match Fedora Packaging guideline.

The only python2 runtime for fedora 14 is python 2.7, you may have to package plone4 for fedora. Fedora also don't want to ship deprecated software is distributions[2]

[1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects
[2]http://fedoraproject.org/wiki/Objectives.

(In reply to comment #4)
> Bundling several projects in one rpm is strictly forbidden by Fedora[1] and
> many other linux distributions like debian, gentoo. You should package every
> python egg seperately to match Fedora Packaging guideline.

well, plone3 has at least 110 eggs and plone4 has at least 270 eggs
do you think this is possible to pack each egg to separate rpm?
and don't forget about different versions of plone has different eggs version requirements.

> The only python2 runtime for fedora 14 is python 2.7, you may have to package
> plone4 for fedora. Fedora also don't want to ship deprecated software is
> distributions[2]
> 
> [1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects
> [2]http://fedoraproject.org/wiki/Objectives.

i want make rpm for EPEL5

(In reply to comment #5)
> (In reply to comment #4)
> > Bundling several projects in one rpm is strictly forbidden by Fedora[1] and
> > many other linux distributions like debian, gentoo. You should package every
> > python egg seperately to match Fedora Packaging guideline.
> well, plone3 has at least 110 eggs and plone4 has at least 270 eggs
> do you think this is possible to pack each egg to separate rpm?
> and don't forget about different versions of plone has different eggs version
> requirements.

So we may need to write some scripts to help us to maintain so many eggs in fedora. Please note bundling many python eggs in one rpm is absolutely unacceptable by Fedora.

> > The only python2 runtime for fedora 14 is python 2.7, you may have to package
> > plone4 for fedora. Fedora also don't want to ship deprecated software is
> > distributions[2]
> > 
> > [1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects
> > [2]http://fedoraproject.org/wiki/Objectives.
> i want make rpm for EPEL5

No sure if one can make a EPEL5 only package which is also useful for Fedora. Normally all package should be built for Fedora rawhide first except some special packages(e.g. python26).

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.

Hey Robin,

(In reply to comment #1)
> * The package 'plone', though retired, has already been in Fedora. You should
> request for surviving that package instead of submitting the same package with
> a different name.
> 
> Refer to: https://admin.fedoraproject.org/pkgdb/acls/name/plone

The main difference with the package we submitted is that it does not use a buildout based approach to bundle Python egg dependencies. Something worth noticing is the fact that we were thinking of providing 2 RPMs for Plone:

 - plone-core: zope and plone core libs bundled as eggs using buildout (the one we submitted)
 - plone-default: default buildout configuration depending on plone-core
   Here it would contain default policies such as the numbers of Zope clients / ZEO or single client instance / object cache size, number of threads etc...

Advantage of this separation is that a custom application could be simply built using a "standard" buildout and then be packaged as an RPM that would then define plone-core as a dependency.  

On very important thing to notice is that if devels are not able to use buildout to define their custom Plone application and then be able to generate a RPM based on a buildout, in a *transparent* way, they will simply *not* use any RPMs at all. I believe this is one if the key point here: the RPM generation has to be transparent for developers and no involve any changes at application level.

But yes, we could try to resubmit using the same name and try to survive that package. The challenge will probably be around backward compatibility depending on how that package had been implemented. 

Thank you for the pointer we will take a look.

> * You should submit the latest version of that package for review. The latest
> version of Plone is 4.0.
> 
> Refer to: http://pypi.python.org/pypi/Plone/

We are actually planning on doing it but at first we need the latest Plone3.x stable release in the / a repository as we are sponsored on our side to implement and maintain these packages.

> * If you are sponsored, you may help updating Plone for epel5, which needs
> Plone 3.
> 
> Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=497933

This is our actual primary target: RHEL5

Please note that we already have in place continuous integration taking care of building RPMs automatically for different platforms in house. We will be glad to offer infrastructure for others Zope based packages if needed. We are in the process of migrating from buildbot to Hudson at the moment and we should be done beginning of next week with public builders for the RPMs we submitted.

Again thank you for the pointer. We will take a look at it.

> * Will you join the Zope SIG? We are a little group trying to package all Zope
> programs, including Zope2, Plone, Grok, BlueBream, etc., for Fedora.
> 
> Refer to: https://fedoraproject.org/wiki/SIGs/Zope

Absolutely, how can I join?

I would be happy to answer questions and provide you more information.

Thank you.

  J.

Hey,

I do not see any questions or feedback after my 2 previous comments. Does it mean there is no interest in discussing this on your side? 

Let me know.

Thank you.

   J.

We welcome you to the python-devel mailing list[1] of Fedora, and let's talk there. We must come up to higher level of agreement, if we are deploying a packaging approach significantly different from other Python packages in Fedora.

I think we all have a wish to make Zope/Plone available in Fedora repository.

[1] https://admin.fedoraproject.org/mailman/listinfo/python-devel

I would prefer to talk about Plone 4 at first.

I agree that it would be hard to maintain if we make a RPM for each application level eggs. But if we build an all-in-one RPM for Plone, and a user want to deploy a Zope configuration without Plone, then, shall we build another all-in-one RPM for Zope or tell him to install the all-in-one Plone instead?

So, all-in-one bundles may be not acceptable. At this time, I may suggest to separate that all-in-one RPM for Plone into several parts:

- ZTK
Packages in the ZTK collection is packaged RPMs per egg.

- ZODB
We have a RPM for the egg of ZODB3.

- Zope
A bundled RPM contains the eggs of Zope2 and all its dependencies other than ZTK, ZODB and existing packages(like Paste).

- Plone
A bundled RPM contains, you know, others.

We should have some general principles:

- All the sources packages specified in Source*: lines should come from the actual upstreams other than third parties.

- We should not make duplications of existing packages.

- We should try our best to make all the RPMs parallelly installable.

Hey Robin,

(In reply to comment #11)
> I would prefer to talk about Plone 4 at first.

We can talk about Plone4 first.  Please note that this is very critical for us to be able to move forward with Plone3 at the same time though.

> I agree that it would be hard to maintain if we make a RPM for each application
> level eggs. But if we build an all-in-one RPM for Plone, and a user want to
> deploy a Zope configuration without Plone, then, shall we build another
> all-in-one RPM for Zope or tell him to install the all-in-one Plone instead?

You are right, we do not want to force a user to install a all-in-one Plone bundle and we believe having a ZTK, Zope, ZODB and Plone RPMs is reasonable.

> So, all-in-one bundles may be not acceptable. At this time, I may suggest to
> separate that all-in-one RPM for Plone into several parts:
> 
> - ZTK
> Packages in the ZTK collection is packaged RPMs per egg.
> 
> - ZODB
> We have a RPM for the egg of ZODB3.
> 
> - Zope
> A bundled RPM contains the eggs of Zope2 and all its dependencies other than
> ZTK, ZODB and existing packages(like Paste).
> 
> - Plone
> A bundled RPM contains, you know, others.

We would be fine with this approach on our side for Plone4. For Plone3.3.5, the ZTK is out of the picture but the principle remains the same.

We can move forward and generate these RPMs and update the Plone3 RPMs to depends on these new ones as well as package Plone4.  Let me know if you believe we should move forward with this on our side? As I said, we are committed to maintain these on the long term as this is critical for some of our customers.

Would you would like to continue this discussion on this ticket or on the actual python-devel mailing list? 

Let me know please.

Thank you.

   J.

The python-devel mailing list is preferred. You should first make a post, otherwise I don't know whether you have been listening to the list.

(In reply to comment #14)
> The python-devel mailing list is preferred. You should first make a post,
> otherwise I don't know whether you have been listening to the list.

Will do Robin.

is there any progress here?