[rt-users] Frustrating attempts to install RT3.8 from RPM

[Gary Greene]

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" <wmodes at 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" <wmodes at 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" <wmodes at 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