Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
The OpenSuSE build service has a lot of good information about using the Build Service for packaging perl modules, see http://en.opensuse.org/openSUSE:Packaging_Perl and http://old-en.opensuse.org/Packaging/Perl. The can easily be adopted for building locally. All the perl packages needed for a default RT installation are available in the perl development language repo, http://download.opensuse.org/repositories/devel:/languages:/perl/. I ran into missing packages for RTIR but was able to build rpms for them using the above information. Additionally, I imported them into my personal repository with the goal of having them included in the perl repo but ran into a couple minor issues which I haven't had time to address. This are build service glitches I'm not sure how to overcome and have nothing to do with the packages themselves. -- Darin Perusich Email: darin.perus...@ctg.com Office: 716-888-3690 Cell: 716-807-4589 -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users- boun...@lists.bestpractical.com] On Behalf Of John Arends Sent: Monday, December 13, 2010 7:14 PM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6? On Dec 13, 2010, at 6:06 PM, Gary Greene wrote: On 13/12/10 9:43 AM, John Arends jare...@illinois.edu wrote: CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. This is why I use cpan2rpm every time. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. This ALSO can be avoided, if you know how to package your cpan2rpm packages in site instead of vendor locations. This allows that NONE of the issues that are endemic of RHEL's busted Perl packaging to cause long term headaches for me. Do you know of a guide that explains how to do this? The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient of this message, please contact the sender and delete this material from this computer.
[rt-users] Possible to downgrade DB from 3.8 to 3.6?
Hello, I am thinking of migrating an RT instance from a machine running RT 3.8.1 to a machine running 3.6, but I'm not sure if this is even possible? Is it possible to move the MySQL DBs straight across from 3.8 to 3.6 without any issues? If there are any tweaks to be done, are they major? I am trying to use a Redhat machine which only has the official EPEL RT packages which are currently only at 3.6. If I can't move the DBs across, is there perhaps a way I can perform a default install on 3.6, then export / import the old (3.8) data in? Thanks for any insight, Khusro
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
On Mon, Dec 13, 2010 at 01:50:44PM +, Khusro Jaleel wrote: I am thinking of migrating an RT instance from a machine running RT 3.8.1 to a machine running 3.6, but I'm not sure if this is even possible? Is it possible to move the MySQL DBs straight across from 3.8 to 3.6 without any issues? If there are any tweaks to be done, are they major? There are some pretty major schema differences, in particular encodings. I can't recommend against this enough. I am trying to use a Redhat machine which only has the official EPEL RT packages which are currently only at 3.6. If I can't move the DBs across, is there perhaps a way I can perform a default install on 3.6, then export / import the old (3.8) data in? Not really -kevin pgpoHwcTUsr7z.pgp Description: PGP signature
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
RedHat is god, ftw! On 12/13/10 10:59, Kevin Falcone wrote: On Mon, Dec 13, 2010 at 01:50:44PM +, Khusro Jaleel wrote: I am thinking of migrating an RT instance from a machine running RT 3.8.1 to a machine running 3.6, but I'm not sure if this is even possible? Is it possible to move the MySQL DBs straight across from 3.8 to 3.6 without any issues? If there are any tweaks to be done, are they major? There are some pretty major schema differences, in particular encodings. I can't recommend against this enough. I am trying to use a Redhat machine which only has the official EPEL RT packages which are currently only at 3.6. If I can't move the DBs across, is there perhaps a way I can perform a default install on 3.6, then export / import the old (3.8) data in? Not really -kevin
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
I don't understand people's desire to use 3rd party RT packages. You're then at the mercy of the packager, and it makes it harder to fix problems and apply upgrades when new RT releases come out. It's better to learn the internals of RT and deal with its idiosyncrasies than to use a package you find somewhere. They're almost always extremely outdated, and require quite a bit of configuration. My RT setup has enough customizations that I keep track of separately that fighting with someone's RPM package would end up costing me far more time that it'd save. Don't get me wrong, I'd *LOVE* *LOVE* *LOVE it if Best Practical official had RPMs available and would use them in a heartbeat, it would make my life easier, and make me a happier person as well as make RT easier to maintain, but 3rd party RPMs are annoying. Don't use them, just install RT per the instructions. 3.8 is such an improvement over 3.6 if anyone made me go back I'd be very cranky about it. On 12/13/10 10:06 AM, Jacob Ritorto wrote: RedHat is god, ftw! On 12/13/10 10:59, Kevin Falcone wrote: On Mon, Dec 13, 2010 at 01:50:44PM +, Khusro Jaleel wrote: I am thinking of migrating an RT instance from a machine running RT 3.8.1 to a machine running 3.6, but I'm not sure if this is even possible? Is it possible to move the MySQL DBs straight across from 3.8 to 3.6 without any issues? If there are any tweaks to be done, are they major? There are some pretty major schema differences, in particular encodings. I can't recommend against this enough. I am trying to use a Redhat machine which only has the official EPEL RT packages which are currently only at 3.6. If I can't move the DBs across, is there perhaps a way I can perform a default install on 3.6, then export / import the old (3.8) data in? Not really -kevin -- John Arends jare...@illinois.edu Network Analyst College of ACES ITCS University of Illinois at Urbana-Champaign
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
On 13/12/2010 16:26, John Arends wrote: I don't understand people's desire to use 3rd party RT packages. You're then at the mercy of the packager, and it makes it harder to fix problems and apply upgrades when new RT releases come out. It's better to learn the internals of RT and deal with its idiosyncrasies than to use a package you find somewhere. They're almost always extremely outdated, and require quite a bit of configuration. My RT setup has enough customizations that I keep track of separately that fighting with someone's RPM package would end up costing me far more time that it'd save. Don't get me wrong, I'd *LOVE* *LOVE* *LOVE it if Best Practical official had RPMs available and would use them in a heartbeat, it would make my life easier, and make me a happier person as well as make RT easier to maintain, but 3rd party RPMs are annoying. Don't use them, just install RT per the instructions. 3.8 is such an improvement over 3.6 if anyone made me go back I'd be very cranky about it. I'm stuck between a rock and a hard place, then. The Redhat people are telling me to *avoid* CPAN like the plague, and most people [1] seem to have accomplished the install on CentOS systems using a combination of packages + CPAN, which is something else that is NOT recommended to do. I wish Best Practical did come up with their own packages, especially for Redhat, it would make things so much easier. [1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. Once I figure this out, I do the same process on the production RT system during a maintenance window. It actually works out pretty well now that I am used to this, but it is less than ideal. RHEL is a major platform, and I'd love it if BestPractical supported it in some official way so we don't have these kinds of problems we have to work around. Still, I love RT and praise it to anyone who will listen. On 12/13/10 11:04 AM, Khusro Jaleel wrote: I'm stuck between a rock and a hard place, then. The Redhat people are telling me to *avoid* CPAN like the plague, and most people [1] seem to have accomplished the install on CentOS systems using a combination of packages + CPAN, which is something else that is NOT recommended to do. I wish Best Practical did come up with their own packages, especially for Redhat, it would make things so much easier. [1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
On Mon, Dec 13, 2010 at 11:43:14AM -0600, John Arends wrote: CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. Once I figure this out, I do the same process on the production RT system during a maintenance window. It actually works out pretty well now that I am used to this, but it is less than ideal. RHEL is a major platform, and I'd love it if BestPractical supported it in some official way so we don't have these kinds of problems we have to work around. Still, I love RT and praise it to anyone who will listen. On 12/13/10 11:04 AM, Khusro Jaleel wrote: I'm stuck between a rock and a hard place, then. The Redhat people are telling me to *avoid* CPAN like the plague, and most people [1] seem to have accomplished the install on CentOS systems using a combination of packages + CPAN, which is something else that is NOT recommended to do. I wish Best Practical did come up with their own packages, especially for Redhat, it would make things so much easier. [1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome It is probably better to remove perl from the list of packages that are automatically updated and apply those manually, if they are needed. Cheers, Ken
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
RHEL is a major platform, and I'd love it if BestPractical supported it in some official way so we don't have these kinds of problems we have to work around. I try pretty hard not to push the commercial side of the business on the mailing lists, but BPS _is_ a business and we tend to spend our time on things that are most likely to benefit the folks who keep a roof over our heads and food on the table. We tend to spend the most effort on the things that our customers use and need. The best way to help us have the resources to focus on official RPMs is to buy a support contract. Best, Jesse
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. I've done this quite successfully. I've got RH distributed perl + packages plus those that I've manually packaged for RT to operate correctly living side by side. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. I've not had a RH update break my RT system in over a year, and that was because one of my packages was badly done. You just have to figure out which packages are conflicting badly (CGI, Encode and File::Temp for instance) and make sure it's using vendor_perl instead of site_perl installation locations and sometimes relocate some man pages to avoid conflicts. I am used to this, but it is less than ideal. RHEL is a major platform, and I'd love it if BestPractical supported it in some official way so we don't have these kinds of problems we have to work around. Still, I love RT and praise it to anyone who will listen. Agreed :) Stuart
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
On 13/12/10 9:43 AM, John Arends jare...@illinois.edu wrote: CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. This is why I use cpan2rpm every time. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. This ALSO can be avoided, if you know how to package your cpan2rpm packages in site instead of vendor locations. This allows that NONE of the issues that are endemic of RHEL's busted Perl packaging to cause long term headaches for me. Once I figure this out, I do the same process on the production RT system during a maintenance window. It actually works out pretty well now that I am used to this, but it is less than ideal. RHEL is a major platform, and I'd love it if BestPractical supported it in some official way so we don't have these kinds of problems we have to work around. Still, I love RT and praise it to anyone who will listen. On 12/13/10 11:04 AM, Khusro Jaleel wrote: I'm stuck between a rock and a hard place, then. The Redhat people are telling me to *avoid* CPAN like the plague, and most people [1] seem to have accomplished the install on CentOS systems using a combination of packages + CPAN, which is something else that is NOT recommended to do. I wish Best Practical did come up with their own packages, especially for Redhat, it would make things so much easier. [1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome -- Gary L. Greene, Jr. IT Operations Minerva Networks, Inc. Cell: (650) 704-6633 Office: (408) 240-1239
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
On Dec 13, 2010, at 6:06 PM, Gary Greene wrote: On 13/12/10 9:43 AM, John Arends jare...@illinois.edu wrote: CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. This is why I use cpan2rpm every time. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. This ALSO can be avoided, if you know how to package your cpan2rpm packages in site instead of vendor locations. This allows that NONE of the issues that are endemic of RHEL's busted Perl packaging to cause long term headaches for me. Do you know of a guide that explains how to do this?
Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
I've been working on one for SuSE on the wiki. I'm still a little behind on getting it all done. On 13/12/10 4:14 PM, John Arends jare...@illinois.edu wrote: On Dec 13, 2010, at 6:06 PM, Gary Greene wrote: On 13/12/10 9:43 AM, John Arends jare...@illinois.edu wrote: CPAN makes me cranky, but trying to package all the perl modules as RPMs makes me crankier. It's like wrapping one packaging system around another one, and fighting with both of them. This is why I use cpan2rpm every time. The reality is, every time RHEL updates perl, RT will break. I solve this by having an identical test system. I apply the updates, see what breaks, and then reinstall the perl modules in question using CPAN. This ALSO can be avoided, if you know how to package your cpan2rpm packages in site instead of vendor locations. This allows that NONE of the issues that are endemic of RHEL's busted Perl packaging to cause long term headaches for me. Do you know of a guide that explains how to do this? -- Gary L. Greene, Jr. IT Operations Minerva Networks, Inc. Cell: (650) 704-6633 Office: (408) 240-1239
