[CentOS] Upgrading MySQLdbyg

Mon Jun 28 19:22:11 UTC 2010
R P Herrold <herrold at centos.org>

On Mon, 28 Jun 2010, Les Mikesell wrote:

> On 6/28/2010 1:43 PM, R P Herrold wrote:
>>
>> All RPM needs is for people to read and use the tools, and all
>> this is done well presently
>
> What's the right approach with RPM to have multiple versions of an
> application installed simultaneously?

stow, alternatives, and versioned namespaces already discussed 
in my last post on this thread

>> "Those who don't understand UNIX are condemned to reinvent it,
>> poorly." – Henry Spencer
>
> Yes, but unix was developed from the beginning with the idea of having
> test and production instances installed simultaneously and different
> users having their own different local copies of libraries and
> executables.  It is RPM that doesn't understand those concepts.

I started in the commercial Unix world with HP-UX; in Linux 
with binary TGZ-balls - I recall their approach and HP Depot 
files.  Each are a poor knockoff, compared to the richness of 
expression possible with RPM (or .deb)

RPM understands those concepts well, and supports working with 
the autotools; it will happily set up, build in, an run test 
in 'build chroots' populated to taste with various versions

> And while you are at it, what's the right approach for using RPMs that
> are developed without coordinating their namespaces with all other
> potential sources of RPMs.

This is a political problem, and not a technical one.  LANANA 
is (properly) will not willing to impose a solution, but 
rather to assign namespaces without collision; the FHS offers 
quidance; th LSB is the only 'rosetta stone' interchange point 
of any mass other than defacto ones build up by vendors and 
prominent independents

Answered the other way: the 'right' approach is to avoid poor 
packagers and prefer good ones.  In self defense, I package to 
meet my quality needs, pulling liberally from 'good' peers. 
I see that my archive holds 839 SRPM packages in 350 groups 
listed that all largely interop [or are obsoleted but left 
for others who may want them]

-- Russ herrold