This kind of question will provoke many 'subjective' responses, just an FYI to hold out and get everyone's opinion, as I'm sure they'll give it
As for me:
I've used several different types of package managers, all have their ups and downs. Some are quite a bit more organized, and in fact allow you to choose where things are stored/installed. Take for example, my favorite to date, Gentoo's Portage. Very customizable, as well as extremely verbose. This allows the user to actually physically see what is going on, and in return, build the software to suit their needs. However, there is always a few drawbacks when you aren't hand rolling every package you install. You will likely setup Portage with your most common preferred options, and your 'make.conf' file with your desired compile options. This will be great for a good portion of the applications you install; however it will build ALL packages that way. It's not always your desire, and there are indeed ways to override these options. But that's not the point. In that case, you are then back in the place of tailoring quite a bit of installs simply to do what you already are doing (before using the package manager).
Package management, to me, is a great tool if you:
a. Don't have the patience or knowledge to compile your own applications;
b. Have the need to deploy this distro on MANY machines, all having the same/nearly the same configuration/applications;
c. Require a constant check on package updates, and an easy way to incorporate these updates;
d. Are testing out many tools to see what fits your needs/wants/desires.
There are plenty of other reasons, but for me, those are the reasons I feel that a package manager exists.
Now to answer some of your questions:
Not really an exact quote
If you install something via a package manager, and then later want to install a source version of this package, will it cause problems such as version conflicts and so on?
Yes and no. If you install all your packages by hand into say /usr/local/myapps then no. Your PATH description (shown by typing echo $PATH at the command prompt) will show where your system will look first for executable applications. What this means is:
If you install applications to /usr/local/myapps with ' ./configure --prefix=/usr/local/myapps ' And then append to the END of your $PATH the directory /usr/local/myapps;
and later, your package manager installs an application of a newer/different version to /usr/local/bin and /usr/local/bin appears before /usr/local/myapps in your $PATH variable, then it will be executed instead of the version installed in /usr/local/myapps. Will the conflicting libraries pose a risk in such a situation? Nope. Not to my knowledge. The application will call upon the specific versions of the libs that it requires, and if it doesn't have them, then the dependency isn't satisfied and simply needs to be satisfied. This however is not always true, not even with a package manager. There are always conflicting versions of certain applications, and worse, a necessary dependency may be the confilicting package. In situations like that, I will tend to find a binary version of the application, or see if I can install to a different directory until this is fixed, or until I figure out how to fix the problem.
Ok, well good luck. And as a slacker, you should certainly have and be aware of checkinstall