On Mar 17, 2005, at 00:03, Dennis Peterson wrote:
Dale Walsh said:
On Mar 16, 2005, at 19:33, Dennis Peterson wrote:
Dale Walsh said:
Where are the archives of this list, like for last week? I remember
someone mentioned how to do what I want to do and I think I am almost
right in how I was doing it... I don't intent to install zlib-1.2.2
over my system's zlib!
-Wash
I guess you didn't understand my response.
Doing this upgrade is safe and wont break anything and is recommended.
Installing it in a secondary location is not recommended and the reasons should be obvious!!!
This upgrade is recommended because it fixes some bugs, improves performance and fixes some vulnerabilities.
If you don't want to install it for any reason then give just give up
on building anything that depends on it because without it they wont
build.
Is that any clearer for you?
-- Dale
It's clear to me, Dale, and it's wrong. I wouldn't do it either. I get
my
system libs from Sun, for example, because they are guaranteed to work
with my OS. Anything else goes into /usr/local where my compiled
sources
are told to look for it. Generalizations are usually a bad idea -
including mine. It is best to leave it to each admin to manage the
configuration of their OS's.
In this instance the OP can put the path to his libs in his clamav
configure. If that doesn't work (as revealed by ldd, for example) then
he
can hack the Makefile.
dp
Yes, you can hack the Makefile, but Sun doesn't do anything special to the zlib installation so upgrading this app/library wont have any ill effects.
Rot. They give it a part number, they track dependancies, it becomes part
of the total configuration management system, they upgrade it in a
coordinated fashion and in concert with other dependent packages. Man
pages are replaced, for example, and are placed where pkgadd/pkgrm expects
to see them. pkginfo will give you accurate information about the running
product. This is in no way limited to zlib.
If you do a "./configure && make && make install", it will install in "/usr/local" and you can point ClamAV to this library and it will work as you expect however, you may experience other side-affects by having two versions of zlib installed when library loading/linking occurs by different applications.
User error.
If you're doing this for test purposes, go ahead and do it this way but
if you're wishing to use it in deployment, this is not recommended
based on the problems that it causes unless soft-linking is employed
and very few applications use this linking method.
I'd imagine that if you have 40 different systems to manage with your methodology you'd truely have 40 very different systems.
Considering the problem that occur with loading several different versions of the same application library, it should not pose any serious problem and System Engineers may consider this approach to determine compatibility on a test platform before deploying the application.
Thanks, no. The OP has it right.
dp
Unfortunately you have misunderstood the scope of this topic and the information I have offered as something I recommend as a way of life..
I do have 14 systems to manage and I don't play games with any of them.
Fortunately, the methodology isn't mine, it is the original poster who wishes to install different version of ClamAV and by adding the latest, a version requirement for zlib is being encountered that he doesn't want to install.
All I did was mention the potential problems, suggest that a temporary install for testing purposes as described to me is about his only possible option if he still wishes to test-install the latest ClamAV without overwriting the current system installed zlib.
In your case, you are saying you're basically stuck with the whatever version is available based on your configuration system management provides for you, hopefully they have the latest versions available.
I don't run into this problem, all my systems are the same, latest version of zlib installed, latest version of ClamAV, each system identical, I do a test install on an off-line server and if all works as intended I then deploy the application.
Installing multiple version of zlib doesn't make sense to me because of dependancy issues and issues that System Engineers have explained regarding simultaneous loading/linking of multiple version and the potential problems based on this that I don't want to experience.
Your comments on my comments haven't helped the original poster figure out he should do it the right way, your comments don't really help him at all, you spent too much time attacking what I suggested without acknowledging why it was suggested or even offering an alternative method for him to use.
He doesn't want to overwrite the existing zlib or ClamAV, he wants to install it just to see what the differences are, if you have another way of installing both so he can see the differences I'm sure he'd be happy to read it as would I.
Basically this boils down to the following, if the original poster wants to use the latest ClamAV he has to install the dependent zlib, if it's not available then he will have to create his own installation of it or wait for someone else to create it for him.
Installing something just to see the differences isn't my idea of utilizing a deployed server and the risks of such a faulty install far outweigh the benefits but it's his server and he wants it to do it this way.
-- Dale
_______________________________________________ http://lurker.clamav.net/list/clamav-users.html
