OS is: Red Hat Enterprise Linux ES release 4 (Nahant)

I am building a new Postfix mail server. There are many different packages that need to be built from source tarball some of which must support certain features. My issue is some older versions of the software I need still exist on the system in RPM format.

Here is an example:

I am installing a new version of BIND from source tarball. Here are the rpms that exist from the old version:

bind-utils-9.2.4-2
bind-9.2.4-2
bind-chroot-9.2.4-2
bind-devel-9.2.4-2
bind-libs-9.2.4-2

QUESTION: Would the best practice be to UNinstall all of the old RPM versions first (including every one of the above) and then install the new version of BIND from source? Or is there a better alternative?

NOTE: Some of these source installs will require compiling in certain features so I am not certain that just looking for other existing pre-built RPMs will be a viable alternative. I am not experienced in the building of RPMs. I have done a lot of source builds however and feel more comfortable with that.

What I want to avoid is having pathing conflicts down the road and/or old software on the system that someone else may mistake for the current version if that makes sense.

Please advise...

Thank you,

tigemac

Generally if you must personalise a package without slipping down the path of losing visbility via the rpm database is to use a source rpm rather than the original source itself. firstly this will use the identical code that the original precompiled RPMs are using, including redhat's own patches and such. you can then compile the code pretty much as normal but end up with a RPM to call your own, which you then instll as normal. Personally i suck at compiling source rpms, but that's normally the best route to take if you're generally happy living in RPMville.