[CentOS] Upgrading MySQLdb

Mon Jun 28 15:27:34 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

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