On Thu, Jun 24, 2004 at 08:19:48PM +0300, Yedidyah Bar-David wrote:
> On Thu, Jun 24, 2004 at 12:15:15AM +0300, Tzafrir Cohen wrote:
> > On Wed, Jun 23, 2004 at 10:04:41PM +0300, Yedidyah Bar-David wrote:
> >
> > >
> > > I think the easiest would be to download their binary tar.gz (what
> > > they call 'Linux downloads', the first option in their download page).
> > > I know our DBA installed it more-or-less smoothly on RH73.
> > > Not always RPMs are less work. Unless it's a trivial package, I tend
> > > to install RPMs only from the distributor. Packages that have such
> > > binary, location independent tar.gz's (such as tomcat, java, mozilla,
> > > etc.) are very often easier to install than RPMs. If the problems are
> > > real, e.g. if their binary tar.gz does need a shared lib you don't
> > > have (or a newer one), you _will_ get into trouble, though.
> >
> > You may also get into troubles if the package provides a library you
> > need to link against.
>
> Why?
> Just to make things clear: I do not suggest to put mysql (or any such
> non-trivial thing) directly under /usr/local, with e.g. its libs in
> /usr/local/lib, which can cause trouble (as you said). That's why I
> said 'location independent'. Put it wherever you want (I do in
> /usr/local/lib/mysql-xxx), and link to /usr/local/bin just the things
> you want. And, BTW, I actually don't do exactly even that - I use
> stow (probably soon to be replaced by a similar, better alternative.
> Anyone has substantiated suggestions?).
So what about the mysql client library? Can a mysql 3.23 client connect
to a mysql4 server? Alternatively: is the library interface
backward-compatible?
If not, things like php will need to be relinked with the new library.
rpm (or whatever package management system you use on that system) will
not be aware of anybody on the system that provides mysql 4.0 clients
libraries.
This means that rpm will not know that your system provides the
capability of "mysql client library". Thus no package can rely on it.
This is fine as long as no other package actually needs that capability.
But if you have programs like php, or some programs that you yourself
write.
So what are your options?
1. If a package needs mysql libraries: install it from source and not as
an rpm
Pros: the rpm system is kept consistent
Cons: It's your job to maintain all system libraries. e.g: can you
afford upgrading your openssl? Will upgrading it break any
installed package?
You also have more work in case of security updates. You have
to keep track of all of those packages
2. Install those packages with --nodeps
Pros: simplicity
Cons: you break rpm. IIRC yum will flatly refuse to work on a system
with unsatisfied dependencies. And anyway, this is a source for
problems.
It may break just when you least expect it.
3. If a package currently needs mysql-3.23, rebuild it. This is a
variation of (1)
Pros: Generally involves more work than (1). Though generally
requires less maintinance and the work is easier to automate.
Quite useful if you have to maintain those changes on multiple
computers.
Cons: Again: more work in case of updates. You can't simply install
the vendor's fixes.
4. Create a dummy rpm package: create an rpm package called
mysql-dummy-4.0.20-1 which will satisfy any rquirement that rpm
packages ask for and that the version
Pros: rpm is generally aware of the system's capabilities
Cons: however you are required to manually synchronize what rpm knows
about the system.
--
Tzafrir Cohen +---------------------------+
http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
mailto:[EMAIL PROTECTED] +---------------------------+
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
