The CentOS version is currently 3.8.1, so they're not really a good fit at this time. The SuSE ones are 3.8.8. If you're still interested in them, I can put them on a server outside my office for download (bandwidth at work is.... lacking.)
Far as I know, the changes in /etc are marked config noreplace, however, changing them to config save is fairly easy in the srpm. On 3/11/10 5:24 PM, "Wes Modes" <wmo...@ucsc.edu> wrote: > That is nice to see that you made a well-crafted rpm that you can be > proud of. I wonder what would happen if a later version of RT3 became > available via EPEL. Would it nicely replace the files (maybe moving > stuff to rpmsave's) or would all hell break loose? > > What RT3 version is your centos rpm build? > > When and where would your centos rpm be available to play with? > > W. > > On 11/3/2010 4:45 PM, Gary Greene wrote: >> 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