When you install from source (using
sudo make install), you are responsible for choosing the installation location.
Many software packages will by default install under
/usr/local if installed from source, but you should check the build instructions of the source package and/or run a dry-run installation (often
make -n install, but refer to the build instructions) after building the software but before installing it for real.
When installed under
/usr/local, the software usually should not interfere with the packaged version provided by the distribution, and since the PATH environment variable for regular users normally includes
/bin, the locally built version will usually take priority over the packaged version.
So all should be fine immediately after the installation. But it might become a problem later, when the distribution has been upgraded and the locally-built installation is older than the one packaged by the distribution. If you install locally-built software with
sudo make install, the source package may or may not include a corresponding
sudo make uninstall procedure - and if you have deleted the build directory, the auto-generated
Makefile that might have contained the correct uninstall steps might be gone anyway.
So, if you use
sudo make install, you should record the output of the installation procedure, or otherwise make sure you'll note which files were added by the installation phase, so that you can manually remove them later. Plan ahead. (If the system in question is a single-purpose server, it might be the only software built from source, and so all the files in the
/usr/local/ hierarchy might be produced by that installation - so it might be just a matter of deleting all the files from the directories under
/usr/local after a major version upgrade.)
If the source package happens to include the
debian/rules file, then the source code already includes the configuration necessary to build an actual Debian package. In that case, you can use
dpkg-source -b instead of the generic source building instructions, and the result should be one or more
.deb packages you can install using the package manager.
If the packages are named the same as the distribution's corresponding standard versions, but the version of your locally-built packages is higher, your locally-built packages will automatically be used to replace the distribution's version. Just as when installing distribution-provided updates, the package manager will automatically remove the old version of the package and replace it with the new one.
(You might get a warning from the package manager unless you take extra steps to cryptographically sign the packages you built, depending on which package management tool you use, but since you just built the packages yourself, you presumably trust them.)
In this case, once the distribution's package repository has a version of the software that has a higher version number than your locally-built package, the package manager will automatically suggest an upgrade, just like when upgrading the standard packages.
With both the generic source build instructions and the Debian-specific
dpkg-source -b, if the software package you're building depends on some libraries, you'll not only need to have the compatible versions of those libraries installed (the build instructions will usually list the required minimum versions of the required libraries) and also the development packages for those libraries, so that the compiler will know how to use the libraries.
The name of the development package is usually the same as the name of the corresponding library package with a
-dev suffix added, but sometimes the library package name may include some version numbers that are omitted from the development package name. (In these cases, there may be several versions of the library available for backward compatibility, but the development package either covers both or just the newest version.)
It sounds like you've already compiled the new version successfully, so this is probably not relevant to you... but when building a newer version of software from source, you might find that it needs a newer version of some library or other than is available in the distribution... and a newer version of that library needs a newer version of some other library to compile... and so on. While it's possible to traverse the chain of dependencies and build local versions of the required libraries if there are not too many of them, it is important to not go too far. Providing new versions of one or two special-purpose libraries is probably fine, but if you start building upgraded versions of libraries that are used by several system components, you probably should consider switching to a newer distribution instead. Compiling a new version of
glibc locally and installing it for system-wide use is right out.