Thanks for the suggestion - I appreciate your concern. Better packaging has been long on our wish list but the list is long and the amount of hours in a day is not.

Yeah. These days it’s a real distinguishing factor, especially for enterprise-grade stuff. IBM and Oracle get this one wrong most of the time, and we yell at them too. 8-)

Enterprises don’t have time or extra bodies to deal with software that doesn’t work easily with the native software management strategy and tooling. You’re getting into the big time, and special cases that don’t use the native packaging systems (and have sub-packages that aren’t represented in the native packaging system) are a real PITA for configuration-managed environments. Special cases = bad for enterprise management.  

But, anyway. It’d do a lot to make testing easier if we could just set up a virtual machine, tell it where the latest version is, and just “yum install” to pull in all the other stuff OTRS needs. With that, I can easily create test instances and use the time to test the software instead of building the environment to test it. 8-)

Anyway, to be able to pull this off the upgrade process for patch level updates should be fool proof and should not require manual actions.

Desirable, but not in the critical path. I’d really settle for just having a repo to get the known current stable and beta builds (one for each). That’d be good enough for now.  (In fact, I’d look at something like what OpenERP does – provide a daily build of the stable release in a known location and leave it at that. I don’t mind doing the additional steps while you evolve packaging strategies).

Currently, it would still require manual reinstallation of packages via the OTRS package manager in case you are using ITSM, for instance. This should be taken care of by the RPM. That is totally fixable.

A dummy RPM for each OTRS internal package that did the OTRS pkg mgr install commands in the postinstall script probably would be sufficient. Something similar to the RPM packaging of the CPAN libraries would be super, and could be programmatically generated.

And we should create different repositories for the different minor revisions, so if you would like to upgrade from OTRS 3.1 to 3.2 you could do that by changing your package repository and running yum upgrade plus any post install actions, and if you would not change the repo you will keep on receiving 3.1.x updates.

Holy Grail. 8-) See above. That can come later. Focus on the initial sw distribution problem for new builds first. Much smaller task.

Ø One other topic is that we currently do not ship with an SELinux profile, which forces people to set selinux to permissive.Would there be any RHEL syadmin that can help with the SElinux profile?

If you can give me a log file from running a production OTRS in permissive mode/with “setenforce 0” on for a couple weeks, I can get someone to look at it and come up with a proposed policy file. We’re in the middle of doing a bunch of other profiles, one more won’t be a huge hassle. 8-)

Would there be people interested in testing such an RPM repo?

YES. I’ve got virtual machines just sitting here waiting to try it.

(Something else that just occurred to me: if you do this, it’d be trivial to use VMWare Studio to build a complete ready-to-use OTRS appliance image. THAT would be cool – base it on Centos or OpenSUSE, and distribute a complete known working system, either for testing or real use. Would save a huge amount of startup questions – if you do the repo, I’ll try generating one. )