On 6/28/2010 9:46 AM, Whit Blauvelt wrote: > On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote: > >> It actually counts for probably 20-30% of all the support necessary on >> the irc channels with people trying to update php/mysql or similar >> from source. > > A large part of that problem is that people are asking for support in the > wrong place, right? No, the fact that your ability to 'yum update' and have the right thing happen is broken is a big problem regardless of who/where you ask for help. Even if you break it yourself, it is bad that it is broken. >> However recommending that someone else do this isn't always the safe/smart >> play. If they don't have the same grasp you do, and they blow up their >> system because they didn't understand it... YOU, and to a lesser degree >> the mailing list/distro are going to get the blame because you told them >> it was the best way to go. > > I get it, it's a "Do as I say, not necessarily as I do" situation because > those committed to providing support through the mailing list (which CentOS > is exemplary on) don't want to have to support stuff that's outside the > scope of CentOS. That scope boundary gets fuzzy if there are too many > references to going beyond the RPM system in list comments. Perhaps each > such reference needs a footnote: "You might do this, but go somewhere else > for support of it." Think of rpm as a database with consistency rules needed to manage your system - and yum as an application that requires database consistency. Because that's what they are. Now think about what happens when you randomly scribble over database values, ignoring the consistency rules. Because that's what you are doing when you replace file contents that rpm thinks it is managing in its database. >> It may be ivory tower thinking, but to me it doesn't matter if it's >> debian, ubuntu, centos, fedora, or whatever else. You use the tools >> and package managers specific to your distro. to help keep things sane >> for others. > > Sanity here is relative. Does anyone ever think their own choices are not sane - even when they aren't? > If you go to the main support channels for stuff > like Apache or PHP or Python or Postfix or whatever, and you're having > trouble because of some bug that they fixed literally years ago, but which > your distro of choice doesn't yet provide packaged, you'll find no patience > for the "I'm not going to compile your current version because then my > distro would be impure" excuse for not upgrading to fix the problem. > > So from their POV it's insane that you're staying with what they see as an > obsolete, unsupported version. Yet from a distro-centric POV it's insane > that you're not. I get both POV's. I think the take home is: If you need to > go beyond what your distro provides, you need to take your support questions > beyond your distro's channels too. Support isn't so much the point as not breaking your system in the first place. And there are three easy ways to not break it. In order of increasing difficulty: 1) find a yum repo with suitable RPMs already built and maintained (e.g. remi for mysql) and enable that repo only for the yum install and update commands for this particular app. 2) build from source, but be sure everything lands in /usr/local, /opt, or other location completely outside of any packages under rpm control. Track updates yourself and be sure you know how to delete all files that were installed. Do plenty of testing if you use developer source releases - because no one else may have. 3) build/maintain from source and package your own rpm that wins over the stock version and doesn't create additional conflicts. Under some circumstances option 3 may be less work than 2 (spec file already available, multiple machines to maintain, etc.). And since the RHEL6 beta is out, yet another option might be to grab a src rpm from ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/ and see if it will build and install. If it works, that might make for the easiest transition in a future system upgrade - and you would still get a 'fairly well tested' version compared to what might be the latest developer release. --- Les Mikesell lesmikesell at gmail.com