[CentOS] Upgrading MySQLdbyg

[R P Herrold]

On Mon, 28 Jun 2010, m.roth at 5-cent.us wrote:

> R P Herrold wrote:
>> and this random guessing and recordatation to pollute the RPM
>> database "varies from ** and ** is better than" using a
>> package built from a pre-defined recipe driven by a .spec
>> file, just how?

> Well, when it insists on building in /usr/src/redhat,

bzrrrttt --- no such insistance by RPM; just the opposite as 
it it is fully configurable -- also building as root is a well 
known and readily avoidable stupidity
 	http://www.owlriver.com/tips/non-root/

> to me a week or two ago.... I'd *MUCH* rather have one directory, with
> everything in it related to whatever I was building, and have *one* place
> to tell it what it needed to find (such as the above).

Nothing in RPM building practice prevents gathering local 
collections of packages that relate to one another -- I've 
published such cluster collections to satisfy dependencies for 
years and years
 	ftp://ftp.owlriver.com/pub/mirror/ORC/bugzilla/

> Right. And the folks who build packages and don't even consider the
> possibility of looking at a *higher* subrelease of a library (had that a
> number of times)

Namespace collisions are the responsibility of the craftsman, 
not the tool, of course; stow and alternatives work perfectly 
fine if one 'needs' to swap between such in build 
environments; packages using autotools and 'configure' 
sensible and richly also readily provide for parallel 
versioned library installs -- not RPM's job, mon

> We won't even begin to talk about python....

The Python community tout weak type checking as acceptible, 
along with limited namespace disambiguation tools; they lack 
the interest to follow the convention of holding an API stable 
across a major version number, and so transfer the burden to 
their using community.  I understand why it seemed like a 
better choice than say, perl, to Red Hat, but there are some 
major faults in Python space as well

-- Russ herrold