The CentOS ones follow the RH way of directory layout, with the caveat that I chose to put the other modules that normally get pulled in via cpan in the perl5 site_lib hierarchy to assure that a rouge update from rpmforge or upstream CentOS would be able to be installed without odd file conflicts.
The SuSE ones I did slightly differently as I think having the main RT stuff strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib hierarchy as before, but the main HTML/Mason templates/RT only specific modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in /etc/rt and the plugin configuration directory is /etc/rt/local/... If I were to do over the CentOS ones, I'd likely do the same as I did with SuSE. On 3/11/10 4:36 PM, "Wes Modes" <wmo...@ucsc.edu> wrote: > I presume that is CentOS5. That would make me very happy as CentOS RPMs > should work for RHEL. > > One thing I adore about well-built packages is that things are placed in > the right location for the OS. For instance, the RT3 rpms put all the > config files in /etc, all the perl modules in the perl modules dir, and > the various tools in /usr/bin and /usr/sbin. > > Is yours built that way, or does it keep to the Best Practical distro > locations? > > i guess this means that no one has a solution to the problem I observed > with the rpm bundle I did find, ya? > > Wes > > > On 11/3/2010 11:52 AM, Gary Greene wrote: >> Agreed. This is why I spent a week with cpan2rpm and built packages for both >> openSuSE (which we're transitioning to) and CentOS. >> >> >> On 3/11/10 11:21 AM, "Wes Modes" <wmo...@ucsc.edu> wrote: >> >>> Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS, >>> so I'm guessing yum feels like an inconvenience to you, especially when >>> it seems to be getting in the way of your desired install. >>> >>> I've been a sysadmin for 20 years and I've never been a fan of the make >>> 'n' break style of system administration. There is no way I could >>> manage a score of machines, many with subtly different hardware, if I >>> had to build every package the old way. As it is, I can spend a few >>> hours monthly updating the OS and all installed software on all of our >>> machines, with a simple "yum -y update" >>> >>> In my opinion, package managers like apt-get and yum are some of the >>> best things to happen to OS in a very long time. Having installs >>> tracked and managed by package managers keeps complicated OSs and their >>> installed software up-to-date, eases system administration (especially >>> as the server to sysadmin ratio increases), increases scalability, >>> increases sysadmin efficiency, and creates standards for software >>> manufacturers. >>> >>> If as a conservative sysadmin you prefer to operate well-back from the >>> bleeding edge anyway, the small trade-off in control is a small price to >>> pay. >>> >>> It is hardly the package manager's fault if a software manufacturer such >>> as Best Practical and its user community fail to create a package for >>> the latest software. Compare that to software whose RPMs are kept >>> relatively up-to-date. >>> >>> Wes >>> >>> On 11/2/2010 3:49 PM, Paul wrote: >>>> On 11/02/2010 02:19 PM, Wes Modes wrote: >>>>> Hello, I have been struggling with attempts to install RT3.8 via RPMs. >>>>> >>>>> I know it is perfectly possible to install RT3.8 using the BP install >>>>> scripts and docs, but I'd prefer to do it through yum for system >>>>> sustainability, ease of updates and upgrades, etc. >>>> ... >>>>> If I can't resolve this, I will just forget about RT3.8 and stick with >>>>> RT3.6 of which there is a well-behaved RPM already in the EPEL repo. >>>>> >>>>> Wes >>>>> >>>> I'm currently going through a RT move from freebsd to rhel5 (long story, >>>> would rather stay with freebsd but don't have a choice here) and have >>>> found all kinds of annoying difficulties with yum (or, rather, the >>>> packages available.) When I realized that I was trying to stick with yum >>>> for ease of upgrades when yum was preventing me from easily keeping up >>>> to date, life got a lot easier. >>>> >>>> In the end I just let cpan install what it could and used yum for the >>>> things that gave me trouble in cpan. Using RT's configure and make >>>> targets is a lot easier and much more maintainable than having to roll >>>> my own rpm just to do it the yum way. >>>> >>>> Being stuck with an old version of the software in the name of easy >>>> upgrades didn't make sense to me. >>>> >>>> Cheers, >>>> Paul -- Gary L. Greene, Jr. IT Operations Minerva Networks, Inc. Cell: (650) 704-6633 Office: (408) 240-1239