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