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 _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
