[mythtv-users] OT: Upgrade to Mysql 5.0

Douglas Wagner douglasw0 at gmail.com
Mon May 1 21:20:37 UTC 2006


Sorry for the "off topic" reply here folks...

RPMs are typically created for RedHat and RedHat equivalent (mandrake, etc)
systems.  Redhat decided a LONG long time ago (in a galaxy very near here)
that single directories with a bunch of programs in it (which is typically
what happened with slackware's tar.gz method) seperated by program (so
100000000 different ./bin directories) wasn't supportable then or in the
future.  It was fine back when slackware was the only name in the
distribution business (back then slackware was distributed on like 25 or 30
floppy disks, 90% of the programs were OS programs, all of which went into
/usr/bin or /bin or /sbin depending on what they were for).  There weren't
alot of addons at that point.

Obviously things have changed a bit these days, with the additional 200 quad
zillion (give or take a package or two :) ) packages that are now available
through the installation, you can't simply keep only the os files in
/usr/bin /sbin and /bin, you absolutely need some kind of consolidated
binary area or your PATH line becomes long enough to be completely
unmaintainable.

Redhat solved this by determining that ALL of their binaries go into
/usr/bin (for user programs), /sbin (for system startup and root only
management programs), all libs in /usr/lib (again unless it's a system
library which then goes into /lib), all configuration files in /etc or
subdirectories of such, etc.  To make a long story short (TOO LATE!!!!)
RedHat decided to consolidate everything into one area.  All of their RPMs
do the same thing.

The PROBLEM with this, is that there is no "apache root directory" anymore
(ok bad example, the apache root directory is /etc/httpd but only because
apache.org got smart to the RPM thing and decided that if that's how RedHat
wanted to play they'd just install sim links to God the Universe and
Everything).  This wouldn't be an issue except for the problem that all the
.tar.gz tarballs out there STILL Want to use the old "create a directory and
let everythign install there, we'll have our own /etc, lib, bin, etc."
method and MOST of them want you to specify some kind of "root" directory
for the installation.  Thus, trying to install a tarball onto a redhat
system requires either a doctorate degree in engineering and programming and
being a founding developer of the "configure" subsystem of linux, or it's
damned well near impossible.  I mean, unless you like trying to figure out
where each and every binary is on the system where the lib, etc, bin, sbin,
etc directories are for each file in the tarball and where the tarball
distribution wants to install to and then write a custom 20000 mile long
./configure line to get all the files in the right places, or you LIKE the
concept of poluting /usr/local as what in effect turns out to be a complete
installation hierarchy of linux. (Which becomes worse in that SOME of the
programs will use the pre-created /usr/local/bin, /usr/local/lib, etc
hierarchies and some will install themselves into their own directory
[/usr/local/myProg] and then include /bin, ./lib, /man, etc under
that...bringing back the old slackware days of umpteen gillion /bin
directories to manage by the PATH environment variable.).

Instead of all of this nonsense you are better off slogging through the RPM
system (what in the H E double Hockey Sticks was redhat thinking when they
decided to require 95% of the installed packages be installed or uninstalled
every time you want to upgrade a standalone program like MySQL anyway?  I'd
like to meet the mental brain child that came up with THAT idea in a dark
alley somewhere...I have about 11 YEARS of RPM frustrations to take out...)
or doing what I suggested in step three and just work around the
problem...tho that does pretty much create what i'm complaining about above
with the tar.gz issue.

So the solution i've come up with is to use /opt to store those programs
that are going to be installed/upgraded regularly and use RPM for the rest.
On each system I build (with different purposes obviously) I end up with
anywhere between 0 and 10 packages sitting out in opt managed through
tarball and the rest of the stuff I let yum manage through the RPM system.

Sorry for hijacking the thread and the list for my rant session, i'll return
you to your reguilarly scheduled discussions. :)

--Douglas Wagner

p.s. Glad you got the RPM --force thing to work :)  Myth seems to run JUST
FINE on a MySQL 5.x installation, my FC5 setup seems to be humming along
like a top now *knocks on wood*.

On 5/1/06, R. G. Newbury <newbury at mandamus.org> wrote:
>
> Thanks for the reply. You think like I do: figure out how it SHOULD
> work, and then deduce the route to get there!
> Douglas Wagner wrote:
> > You've got 3 options:
> >
> > 1) Remove MySQL 4.1 (i'm guessing you're on a RedHat distribution given
> > the file places, could be wrong).  You can use RPM directly to try to
> > uninstall MySQL and all it's dependent packages or you can try going
> > into xwindows and to the package manager there (add-remove programs if
> > you're in a recent version of gnome) and remove MySQL from there.
>
> Problem with this route, is that it screams the parts of mysql are
> needed by the other packages: that is, the dependencies go both ways.
>
>
> > 2) Try Upgrading MySQL 4.1 to 5.X in place using RPM, Yum, etc. I don't
> > have a whole lot of experience here, but technically if you have all the
> > packages you need in the same directory when you do the upgrade the RPM
> > system SHOULD be able to figure out a way around it's dependencies to
> > get everything installed.  With some packages (don't know about MySQL)
> > typically you're reduced to upgrading half your operating system to get
> > it to work in this way.  You might try to simply yum install the MySQL5
> > package and see what happens, who knows, this might be the easiest.
>
> Unfortunately mysql is not, to my knowledge, available through yum. I
> got the upgrade to work however, by using 'rpm --force -U MySQL'.
>
> I think that is failed previously because I put the --force -after- the
> -U switch.
>
> > 3) Work "around" the currently installed MySQL.  Doing this requires you
> > to do a few things:
> >
> > * use chkconfig to remove mysqld from the boot up process (optional, see
> > steps at end for modifying mysqld to start your new MySQL istallation at
> > boot, if you wish to do so then don't do this.)
> > * Install the New MySQL version into a new place (I like /opt as it
> > contains all the packages you've upgraded and /usr/local just gets
> > CROUDED with crap), using either binaries or a code distribution (i've
> > used both, both arn't too terribly difficult to put in place).
>
> This route can get really messy. If I went that way, I would find the
> old versions and copy the new ones into the same spots.
>
> What is really weird about this is that the RPM's are from mysql.com and
> they install the program in a completely different manner than the
> Install procedure set out in the tar.
>
> Geoff
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20060501/f8a1567b/attachment.htm 


More information about the mythtv-users mailing list