Spec URL: http://dev.zenoss.org/downloads/rpm/zenoss-2.1.72.spec SRPM URL: http://dev.zenoss.org/downloads/rpm/zenoss-2.1.72-0.fc8.src.rpm Description: Zenoss Core (trunk build)
zenoss requires zope .. and zope requires python2.4 which is older than what included in fedora which is python2.5. nonetheless, i would love to see this package reviewed and its issue of using bundled apps to be resolved. It can stay in RPMFusion while waiting for zope to work on py2.5 (or fedora change its decision, and include py2.4) @Chris, This gonna be a lot of work. IMO, what u need to do first, is separate the ZenossCore codes into one tarball on its own. All of the 3rd party dependencies which is built by the rpm, you will need to change it to use a dependency from Fedora's own package collection ( if its not yet in fedora repo, submit a package for it). Then, you will need to change the install location out of /opt, and put the files in their respective directories in /usr/. I am not assigning this bug to me. It would be better if someone more experienced do this review. - kagesenshi -
s/"RPMFusion"/"RPMFusion and EPEL"/
I will certainly have a look, as time permit. One thing is that there is a Requires for mysql-server. This looks suspicious to me, I think that it should be possible to use a distant server.
The Zope 2.8 and Python 2.4 issue isn't going to be resolved for quite some time. The Zope folks removed a relationship change notification mechanism in 2.9 that we rely heavily on. That keeps us with Zope 2.8 and Python 2.4 for the foreseeable future. The other issue we have is that we have had to patch OSS libraries to fix some of their bugs. We've pushed those patches upstream but some of them have not yet been included in the mainstream release. Here's a list of the libraries we use AND have patched: * MySQL-python-1.2.0 * Python-2.4.4 * Twisted-2.5.0 * ctypes-1.0.1 * epydoc-3.0beta1 * pycrypto-1.9a6 * pyip-0.7 * rrdtool-1.2.26 Here's a list of the libraries we use that are clean: * Yapps-2.1.1 * Zope-2.8.8 * freetype-2.1.9 * libart_lgpl-2.3.17 * libpng-1.2.8-config * libsmi-0.4.5 * nagios-plugins-1.4.5 * pynetsnmp-0.28.6 * pyparsing-1.4.3 * python-snpp-1.1.1 * sendpage-1.000001 * setuptools-0.6c7 * simplejson-1.4 * wmi-0.1.10 We could possibly rely on RPMs for the libs we don't patch.
We support a distant MySQL server. What do you recommend we Require: ?
(In reply to comment #4) > The other issue we have is that we have had to patch OSS libraries to fix some > of their bugs. We've pushed those patches upstream but some of them have not > yet been included in the mainstream release. In that case you'll have to have a look at the corresponding rpms in fedora, and contact the maintainer with your patch (through bugzilla) if the fix isn't already in the fedora/epel rpm. The maintainers are listed in the package database, doc is at: http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb You already know where bugzilla is ;) The fedora and epel cvs is documented (rapidly) here: https://fedoraproject.org/wiki/UsingCvs For RHEL you have to grab the srpm and look within.
(In reply to comment #5) > We support a distant MySQL server. What do you recommend we Require: ? Nothing! I mean not mysql-server. You can document in a README.dist for example that a user may install mysql-server on a fedora/RHEL box to have a mysql server to use with zenoss, but it is outside of the scope of package dependencies.
You should push your patches for: * MySQL-python-1.2.0 * Python-2.4.4 * Twisted-2.5.0 * ctypes-1.0.1 * epydoc-3.0beta1 * pycrypto-1.9a6 * pyip-0.7 * rrdtool-1.2.26 to upstream ;-) Though, I think python 2.4.x will get no more updates from upstream, so that might be the same for the other packages. I've looked at and used zenoss for a little while (and looked into some of the cool Zope stuff it does) but don't have it in production. If I had access to packages, I'd most likely have it in production. I agree with kagesenshi that the best place for the stack is going to be 3rd party, unless you are able to merge your patches upstream or publish clean patches that can be applied to an upstream source tar and then listed in the spec while, of course, not breaking anything. I would, however, enjoy seeing zenoss in the [default] fedora repos. I don't know about it actually happening with patched (and unreleased?) packages and lack of py2.4 support. Zenoss has a unique situation, due to being in the RHX, where they might be able to poke contacts to get python 2.4 support. I will note I brought this up at the last RH Summit and knew this day would come at some point. As I use Zope/Plone extensively, there are python 2.4 packages @ Livna right now. I have to add a few more xml related packages and setuptools here soon but it supports Zope <= 2.10.5 ( I should say versions that run on py2.4 ).
Would it be acceptable if we land all of our files in /usr/local/zenoss rather than spreading them out all over the place (e.g. /usr/lib, /usr/bin, /etc/zenoss)?
No, the file locations should follow the File Hierarchy Standard http://www.pathname.com/fhs/
The FHS 2.3 spec allows files to be located in /opt/<package> so long as <package> is registered if LANANA. I sent in an application to LANANA to register Zenoss for init, cron, package, and provider. When it's approved that means we should be able to land our files in /opt/zenoss and conform with LHS.
Still not right, opt is not for fedora/epel package but for third party packages. In any case the rpm macros, like %_bindir, %_libdir and so on and so forth should be used. An admin may may set those to /opt/bin and so on, but it is not the default case. Not to mention than the application must be on the paths.
Patrice, just wanting a 'clarification' to make sure I understand. A package that is included in Fedora/EPEL is by definition not 'add-on' software and thus falls outside of the definition: ---- 3.13. /opt : Add-on application software packages 3.13.1. Purpose /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider’s LANANA registered name. ---- An addon software though that was completely ISV would be in /opt/<packagename>/ with all of its 'patched' tools residing there.
Indeed, Fedora EPEL packages are not add-on but system packages. Also the main hierarchy is already used by packages in fedora/EPEL, so the /opt and /usr/local hierarchies are left for the local admin and ISVs. For example, the openoffice rpm done by the openoffice community installs in /opt, and I think that it is a good choice, and we don't want to put anything in there.
This looks interesting. If you need help reviewing I can help you out. Yeah we need to use FHS paths in Fedora/RHEL/EPEL.
@Chris Any updates here ??
@chris It has been long since my last ping, in case there is no update soon it will be closed. Thanks
Any news here?
It's been ages since anyone responded, and there's little chance that this will work on Fedora any time soon, so I'm going to go ahead and close this.