Graeme Nichols 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. >
This is a bit far afield for this forum but my view of my job is to know exactly what bits go with what product so that I can, in fact, replace it manually if needed. I don't trust volunteer packagers but only because I know what options and paths I want/need, and that is how I build things. It is my job, again in my view, to know how to uninstall anything I've installed. Sometimes I will create packages - I do this for products that fall under best practices/common tools guidlines. These tools are built and packaged for each architecture and OS version we run. And this is documented in a wiki for others to reference. For a lot of things I build products and let cfengine do the install. This, of course, after the new product has been fully tested. And absolutely there are test suites that each new product has to pass before it rolls out of dev. This is a lot of work but I do it because I don't think anyone else can do it better and certainly they wouldn't have the same level of care and interest in my environment and job success that I do, and if their product fails I have no butt to kick but mine. It comes down to this: I don't need them. And, sadly, you have no assurance that your vendor will be your vendor next week, or next year, or next semester for that matter. Live changes things for volunteers and they move on. That's a risk I'm not willing to take. And your preoccupation with spec files falls flat on it's ass when you consider that many of use don't use Linux systems. It also says you're handing them your responsibility for defining your environment and product options. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
