Bug 435470 - Review Request: zenoss - The Open Source Network Management System
Summary: Review Request: zenoss - The Open Source Network Management System
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-02-29 15:51 UTC by Christopher Blunck
Modified: 2010-06-06 07:17 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-23 18:36:55 UTC
Type: ---

Attachments (Terms of Use)

Description Christopher Blunck 2008-02-29 15:51:26 UTC
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)

Comment 1 Mohd Izhar Firdaus Ismail 2008-02-29 16:20:06 UTC
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 - 

Comment 2 Mohd Izhar Firdaus Ismail 2008-02-29 16:25:18 UTC
s/"RPMFusion"/"RPMFusion and EPEL"/

Comment 3 Patrice Dumas 2008-02-29 16:42:03 UTC
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.

Comment 4 Christopher Blunck 2008-02-29 16:48:19 UTC
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.

Comment 5 Christopher Blunck 2008-02-29 16:49:07 UTC
We support a distant MySQL server.  What do you recommend we Require: ?

Comment 6 Patrice Dumas 2008-02-29 16:58:45 UTC
(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.

Comment 7 Patrice Dumas 2008-02-29 17:01:36 UTC
(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.

Comment 8 Jonathan Steffan 2008-02-29 17:05:55 UTC
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 ).

Comment 9 Christopher Blunck 2008-03-06 19:29:55 UTC
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)?

Comment 10 Patrice Dumas 2008-03-06 20:13:28 UTC
No, the file locations should follow the File Hierarchy Standard

Comment 11 Christopher Blunck 2008-03-06 22:01:31 UTC
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.

Comment 12 Patrice Dumas 2008-03-06 22:12:52 UTC
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.

Comment 13 Stephen John Smoogen 2008-03-07 23:00:59 UTC
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. 

Comment 14 Patrice Dumas 2008-03-08 07:59:36 UTC
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.

Comment 15 Shawn Starr 2008-06-24 01:31:06 UTC
This looks interesting. If you need help reviewing I can help you out. Yeah we 
need to use FHS paths in Fedora/RHEL/EPEL.

Comment 16 Rakesh Pandit 2008-08-16 14:40:54 UTC

Any updates here ??

Comment 17 Rakesh Pandit 2008-09-29 12:34:41 UTC

It has been long since my last ping, in case there is no update soon it will be closed.


Comment 18 Peter Lemenkov 2009-04-19 05:39:21 UTC
Any news here?

Comment 19 Jason Tibbitts 2009-06-23 18:36:55 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.