On Sun, 16 Sep 2007 11:31:55 +1000 "Graeme Nichols" <[EMAIL PROTECTED]> wrote:
> Hello Dennis, > > Thank you. > > On 16/09/2007, Dennis Peterson <[EMAIL PROTECTED]> wrote: > > > > Graeme Nichols wrote: > > > Hi Dennis, > > > > > > On 15/09/2007, Dennis Peterson <[EMAIL PROTECTED]> wrote: > > >> John Rudd wrote: > > >>> Graeme Nichols wrote: > > >>> > > >>>> Anyone any ideas please? > > >>> Build and install from source? > > >> Works every time it's tried as the rpm creators have discovered. > > > > > > > > > One option. But one that is guaranteed to cause future problems on an > > rpm > > > based system. > > > > > > > Only if you continue to not know what you're doing. None of this is a > > problem when you are the one who knows what you're doing, in fact. > > > Well, I have a pretty good idea what I am doing but by no means would I call > myself an expert. I *do* know from my own experience and from others that if > one installs an application from the source code (./configure; make; make > install) you have a better than even chance of having two versions of the > application installed if for some reason a later version of the application > is installed from a rpm package and this can cause some interesting > problems. > > It would be *very* handy if all application tarballs had a 'make uninstall' > option. Only very few bother to include such an option at the moment so it > is a find as find can exercise to remove all the old bits and pieces of an > application before installing a new version. > > Another *feature* that very few developers include in their source tarballs > in a spec file. If they did then one could build an rpm binary package > extremely simply using the command rpmbuild -tb [tarball name]. However, it > does mean extra work and testing for the developers who are doing it in > their own time. The biggest problem in this scenario is the huge number of > distros all doing their own thing, putting files in their own places and not > based on a core standard. It would be easy if all distros were based around > a core standard and their own bells and whistles added around that core > standard. *Perhaps* then a standard spec file would work on all distros but > I guess this is a simplistic view by someone who uses my system as a working > tool rather than a thing to experiment with. > > Thanks for your help as every problem is a chance to learn something. > > Moral of the story? If your system is based on a package manager, such as > Fedora, then stick to it if at all possible. > > -- > Kind Regards, > > Graeme. > _______________________________________________ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://lurker.clamav.net/list/clamav-users.html I sort of disagree with this. You're implying that systems are kept up-to-date to some extent - like it's apart of a sys admins job to blindly do a yum update / apt-get update / windows update / whatever on a regular basis, and expect things to work. This isn't particularly dangerous in a development environment, BUT really can be in a production environment. For example, my mail servers were last rebooted ( to move to a new power supply system ) just over a year ago, and they'd been up since building about 9 months before that. I haven't changed much at all on their configuration in general. However, fully tested installations of sendmail and it's associated milters are installed, built from scratch as and when it is necessary. I test them first, and when I'm happy, I change the minimum required to protect my systems. My internet facing stuff is right up-to-date, though. I think that you're falling into the all too common trap that sysadmin work is really tedious, so the top priority is to use the solution that takes the minimum time to implement, regardless of it's inherent quality. I reckon that package management is *NOT* the solution for a production server. Obviously this is just my opinion, and I know it's not that popular - but it's the distillation of what I have learnt the hard way over more than 23 years ( just checked my CV! ) of relevant experience. Steve. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
