Red Hat Bugzilla – Bug 435470
Review Request: zenoss - The Open Source Network Management System
Last modified: 2010-06-06 03:17:59 EDT
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)
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
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:
Here's a list of the libraries we use that are clean:
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:
You already know where bugzilla is ;)
The fedora and epel cvs is documented (rapidly) here:
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:
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
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
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
/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
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.
Any updates here ??
It has been long since my last ping, in case there is no update soon it will be closed.
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.