FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 06-26-2010, 06:15 PM
Susan Day
 
Default Upgrading MySQLdb

Hi;

I've got MySQLdb installed (bridge to Python) and I can't figure out how
to upgrade it. I did a find and got these paths:



/usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py

/usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc



I don't have mysql-devel installed, so it wasn't that. Please advise.

TIA,

Susan

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 08:22 AM
Tsuyoshi Nagata
 
Default Upgrading MySQLdb

Hi,
(2010年06月27日 03:15), Susan Day wrote:
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
No-way to upgrade to latest python(2.6), MySQL(5.1), sqlalchemy(0.6).
in public centos site.Upstream policy keep running with older version until 2014.

Your answer is just install MySQL5.1 from source code.(make install)
next time requies B, B requires C,...

I found Ubuntu 10.10 support python-sqlalchemy >0.6.
https://launchpad.net/ubuntu/maverick/i386/python-sqlalchemy/0.6.1-1
http://cdimage.ubuntu.com/daily-live/current/
Its easier to build environment than centos.

Tsuyoshi.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 12:54 PM
Jim Perrin
 
Default Upgrading MySQLdb

2010/6/28 Tsuyoshi Nagata <nagata3333333@jp.fujitsu.com>:
> Hi,

> Your answer is just install MySQL5.1 from source code.(make install)
> next time requies B, B requires C,...


That's a horrible idea. At least use the package management system so
that dependencies can be tracked properly. Installing from source
builds directly is bad for a number of reasons.

> I found Ubuntu 10.10 support python-sqlalchemy >0.6.
> *https://launchpad.net/ubuntu/maverick/i386/python-sqlalchemy/0.6.1-1
> *http://cdimage.ubuntu.com/daily-live/current/
> Its easier to build environment than centos.



--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 12:58 PM
Jim Perrin
 
Default Upgrading MySQLdb

On Sat, Jun 26, 2010 at 2:15 PM, Susan Day <suzieprogrammer@gmail.com> wrote:
> Hi;
> I've got MySQLdb installed (bridge to Python) and I can't figure out how to
> upgrade it. I did a find and got these paths:
>
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc


Where did you get python 2.6 from? CentOS has 2.4.3 by default, and
most repos that have newer python packages drop them in /opt or
similar to avoid clobbering the default setup (and yum).


--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 01:31 PM
Whit Blauvelt
 
Default Upgrading MySQLdb

On Mon, Jun 28, 2010 at 08:54:49AM -0400, Jim Perrin wrote:
> 2010/6/28 Tsuyoshi Nagata <nagata3333333@jp.fujitsu.com>:

> > Your answer is just install MySQL5.1 from source code.(make install)

> That's a horrible idea. At least use the package management system so
> that dependencies can be tracked properly. Installing from source
> builds directly is bad for a number of reasons.

I get the theory behind why you say it's a "horrible idea." In practice, not
so much. In many years of building key programs from sourch on top of a
half-dozen different distros, for use on production servers, I have never
had a problem that could be attributed to not going through the distros'
package management systems.

Now, I'm careful that if one program's libraries are going to get used by
something else, that I build that something else by hand too - I'm not
unmindful of dependencies, and if I were obviously stuff could fail.

But seriously, aside from the nice theory about how each package management
system cures all dependency problems (which isn't 100% true), how many
people have actually found themselves in trouble from, say, building their
own LAMP stack on whatever distro, and skipping the package management
system bottleneck entirely? Maybe I've just had rare good luck with it, but
for me it's worked without problems, ever. That said, it's become less
necesary in recent years, as the distro packages have gotten better. Yet I
don't run a single system without a few programs built from source. Despite
the theory, it has _never_ been a problem.

Best,
Whit
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 01:49 PM
Jim Perrin
 
Default Upgrading MySQLdb

On Mon, Jun 28, 2010 at 9:31 AM, Whit Blauvelt <whit@transpect.com> wrote:

> But seriously, aside from the nice theory about how each package management
> system cures all dependency problems (which isn't 100% true), how many
> people have actually found themselves in trouble from, say, building their
> own LAMP stack on whatever distro, and skipping the package management
> system bottleneck entirely? Maybe I've just had rare good luck with it, but
> for me it's worked without problems, ever. That said, it's become less
> necesary in recent years, as the distro packages have gotten better. Yet I
> don't run a single system without a few programs built from source. Despite
> the theory, it has _never_ been a problem.

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. Additionally, if you maintain multiple systems, it's far
easier to build it once within package management, and push out the
updates rather than building on each individual machine. Additionally,
when it comes to software audits, it's nice to be able to say "that
file came from this package, and has (not) been modified since install
using this verification method". Additionally, we get a large number
of questions about removing packages, or getting them back to a
default state. There are loads of packages that don't include 'make
uninstall' functionality, so your average user may be screwed if they
don't have a complete grasp of building

Basically it comes down to this. You're free to manage your systems as
you see fit. Source builds may well work just fine for you because you
seem to be aware of the intricacies involved. 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.

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.


--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 01:54 PM
Whit Blauvelt
 
Default Upgrading MySQLdb

On Mon, Jun 28, 2010 at 08:58:45AM -0400, Jim Perrin wrote:
> On Sat, Jun 26, 2010 at 2:15 PM, Susan Day <suzieprogrammer@gmail.com> wrote:
> > Hi;
> > I've got MySQLdb installed (bridge to Python) and I can't figure out how to
> > upgrade it. I did a find and got these paths:
> >
> > /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
> > /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc
>
>
> Where did you get python 2.6 from? CentOS has 2.4.3 by default, and
> most repos that have newer python packages drop them in /opt or
> similar to avoid clobbering the default setup (and yum).

And if you install Python 2.6.x from source, it by default goes into
/usr/local/, not /usr/.

(Wouldn't it be nice if CentOS had 2.6.5 instead 2.4.3? Python improved
dramatically between those two. My systems all get Python 2.6.5 alongside
2.4.3 because (a) 2.6.5 has a lot of useful features I'm not going to refuse
to use just for CentOS purity, and (b) it's easier to write Python
3.x-compatible code in 2.6.5. Now, if I were going through the package
management system to build 2.6.5 wouldn't that risk _confusing_ the CentOS
stuff with dependencies on 2.4.3 where simply installing to /usr/local/
appears to nicely avoid that?)

Whit
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 02:30 PM
Jim Perrin
 
Default Upgrading MySQLdb

On Mon, Jun 28, 2010 at 9:54 AM, Whit Blauvelt <whit@transpect.com> wrote:

> (Wouldn't it be nice if CentOS had 2.6.5 instead 2.4.3? Python improved
> dramatically between those two. My systems all get Python 2.6.5 alongside
> 2.4.3 because (a) 2.6.5 has a lot of useful features I'm not going to refuse
> to use just for CentOS purity, and (b) it's easier to write Python
> 3.x-compatible code in 2.6.5. Now, if I were going through the package
> management system to build 2.6.5 wouldn't that risk _confusing_ the CentOS
> stuff with dependencies on 2.4.3 where simply installing to /usr/local/
> appears to nicely avoid that?)

On the surface, yes. However /usr/local/bin is in the $PATH first,
ahead of /usr/bin by default. so anything that doesn't call
/usr/bin/python directly causes issues. This is also a common support
theme on irc. Mostly because yes, it would be nice for a newer python,
but that will be coming in 6.x


--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 02:46 PM
Whit Blauvelt
 
Default Upgrading MySQLdb

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?

> 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."

> 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. 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.

Best,
Whit
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-28-2010, 03:27 PM
Les Mikesell
 
Default Upgrading MySQLdb

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@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 11:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org