Red Hat Bugzilla – Bug 607873
Review Request: OTRS - Open Source Ticket Request System
Last modified: 2013-11-09 02:38:32 EST
Spec URL: http://git.ergo-project.org/?p=kolab-fedora.git;a=blob_plain;f=el5/custom-el5-kolabsys.com/SPECS/otrs.spec
SRPM URL: http://koji.ergo-project.org/packages/otrs/2.4.7/1.el5/src/otrs-2.4.7-1.el5.src.rpm
Description: Revival of a previously retired package.
Original review request: #180015
OTRS is an Open source Ticket Request System (also well known as trouble ticket
system) with many features to manage customer telephone calls and e-mails. The
system is built to allow your support, sales, pre-sales, billing, internal IT,
helpdesk, etc. department to react quickly to inbound inquiries.
Various things should probably be improved in this spec file.
All stuff is now installed in /var/www/otrs, which is against current Fedora guidelines AFAIK (should be /usr/share/otrs, right?).
The installed user "otrs" has /var/www/otrs as home dir, which should probably be changed to /usr/share/otrs too then.
The data tree contains various files that can be changed. These should in some way end up in /etc (or maybe /var/lib/...?). First guess is to do this with symlinks, but I didn't try yet (sometimes this doesn't work because an application looks for other files using the directory name of the real path).
As you might have guessed, I'm also working on improving the old package and I'm happy to share my suggestions in this bugzilla entry. I have to add that I'm packaging OTRS 3.0 beta (now a CVS checkout, a real beta is released on August 2, 2010), but except that the interface is fully rewritten, packaging is very similar and can be used for 2.4.7 with very minor changes, AFAICS now.
I've worked on the spec file a little, and come to think of it it needs a complete overhaul...
1) The perl libraries should be in the OTRS* namespace, not the Kernel* namespace.
2) Since the perl libraries have APIs, they should probably live in %perl_vendorlib
3) A separate -doc subpackage is required for the many example scripts
4) The dummy perl requires and perl provides macros should go, and the Kernel/cpan-lib/* directory should be removed entirely.
I'm on a different computer right now so I can't upload the spec but I'll pick it up and throw it out somewhere soon. FWIW; this spec also works for OTRS 3.0.0 beta2, which, frankly, I don't like ;-)
Also don't forget the var stuff (now /var/www/otrs/var/tmp) that is cache stuff that should go to /var/cache/otrs or so. Probably /var/www/otrs should be minimized and mostly contain symlinks to other parts.
Yes, I was aware of all that.
For anyone interested: I did a (yet unfinished) major rewrite of the spec file, so that files are stored in FHS-compliant places. More to come...
(In reply to comment #2)
> 1) The perl libraries should be in the OTRS* namespace, not the Kernel*
> 2) Since the perl libraries have APIs, they should probably live in
Agreed, but for this we need OTRS to change it (I assume you don't want to apply these major changes yourself as a patch?).
> 3) A separate -doc subpackage is required for the many example scripts
> 4) The dummy perl requires and perl provides macros should go, and the
> Kernel/cpan-lib/* directory should be removed entirely.
Ideally, yes, but as long as we can "hide" the internal cpan-lib with a find-provides/requires trick, I can live with it.
Has there been any progress with this?
If not, I highly recommend removing OTRS from EPEL5 (I'd even favour removing it until or if it gets updated to the latest version).
There are over two dozen security flaws in our currently-shipping OTRS.
I've untagged it from EPEL5 at this time. If you want to move forward with this, please do make sure to address all the known security issues before pushing a new one.
Thanks Kevin. Very much appreciate the assistance.
*** Bug 473833 has been marked as a duplicate of this bug. ***
Now that OTRS is removed, can we close this bug or do we still need it open for something?
Closing per few last comments.
I intend to package it again for all Fedora branches in recent weeks.