I was wondering what kind of problems I might have if I were to both use the package manager to install packages as well as installing some from scratch. Are there usually issues with dependencies? Or is there more to it than that?

Packages you compile from scratch should be installed in /usr/local/ If you only do that, and never install the package with the PM (or purge the PM version), you should never have a problem.

This kind of stems from a lab question I have in class and I am confused about how to find the answer. So lets say I did use both the PM and manual installation of packages. What kind of problems would I face?

Starting with the package manager:
When doing a fresh install from cd/dvd, all package dependencies are on the media, and the package manager will install those as needed in order to install the packages you select.
Installing packages not on the media (downloads) is another matter. Some package managers have better dependency resolution than others. You may find yourself try to resolve dependency errors manually in order to get a package installed and working.
Now compiling packages:
If you try to compile a package that has dependency problems, you have to manually resolve those problems by installing the dependent packages. When upgrades to those packages come along, you can't upgrade as easily as you can using one of the package managers (such as rpm or deb packages). You end up haveing to uninstall the old package, then installing the new.
However, applications such as encap or stow can ease the process of source package management, inclucing upgrades, on systems that would otherwise be managed by some package management system. I've tried both, and I prefer encap.
(As a side note, gobolinux takes the concept of source package management as implemented by encap, and applies it to the entire system).

thanks for the input guys, but you havent quite answered me fully. I asked about the issues that come up when using BOTH a PM and installing packages manually.

Say I normally use the PM, but one time I chose to not use the package manger for some reason, is there a chance that I might override (and disrupt) any dependency chains that were set by the Package Manager before I went manual -- and would otherwise be carefully avoided by the PM if it was the one installing the package?

You haven't really answered my question: why should we do your homework for you? There's no magic for "how to find the answer" - that is, there isn't necessarily some page you can find on Google with the title "Problems if you mix a package manager and source installs". Use a little logic - the things you suggest in your last post sound like reasonable worries to me.

when did you ask me any question? and i didnt ask anyone to do my homework for me -- I know the rules here. I even said that this question stems from something i am doing for a lab, so its not even directly my homework. i will try to be more clear from now on. but i guess there's always some jerk waiting to jump all over someone asking for help.

as far as me searching on google, i have been and there is tons and tons of stuff on package management out there -- which i have been trying to read as fast as possible. i am still pretty new to linux and my class is hard, and i understand that i have to do my own learning, but its nice to ask a question on a forum to get a jump on what to look for. up until this morning, i didnt even know what questions to ask to get an idea of what better questions to ask. that is why i joined linuxquestions.com, so that i could get help with questions i have. i am still trying to learn on my own, and i am bound to ask stupid questions from time to time, but know that i am trying.

thanks to the people who gave me input, and i am sorry if i came off rude. you were a help, and i have benefited from your replies. i just needed a little more insight on what happens when you mix the two methods of package installing. if what i originally thought is the main concern, then i can continue on with my assignment.

thanks

ok i found what i was looking for! Wikipedia:

Front-ends for locally compiled packages

System administrators may install and maintain software using tools other than package management software. For example, a local administrator may download unpackaged source code, compile it, and install it. This may cause the state of the local system to fall out of synchronization with the state of the package manager's database. The local administrator will be required to take additional measures, such as manually managing some dependencies or integrating the changes into the package manager.

There are tools available to ensure that locally compiled packages are integrated with the package management. For distributions based on .deb and .rpm files as well as Slackware Linux, there is CheckInstall, and for recipe-based systems such as Gentoo Linux and hybrid systems such as Arch Linux, it is possible to write a recipe first, which then ensures that the package fits into the local package database.

Another way of understanding what is happening if you have both packaged and source versions of the same program is to consider and example like this -

Say you're unhappy with the default program "ping" as provided by Debian (or any distro really). You could compile your own version of ping. You might just want to make your personal ping have a different name, like ping2 in order to be safe, but lets say you compile ping in /usr/local/ and it dumps a copy of your special ping in /usr/local/bin/.

Most of the time, this doesn't cause a problem. If you need the regular ping on your system, you call it with /bin/ping, and if you want your special ping, you call it with /usr/local/bin/ping.

But there is still a potential problem there. When I want to ping something, I don't call either /bin/ping or /usr/local/bin/ping, I just type ping and give it a name or address to ping and away it goes! How do you know which ping you're getting? Type this in a terminal:

You'll get the places (and order) that your system will look for programs. When I check my $PATH, I get this list -

So the first place my machine looks for and program (in this case, ping) is in /usr/local/bin, then it would go to /usr/bin, then /bin, then finally /usr/games. Since my custom compiled ping is in /usr/local/bin, it will always be the first selected.

Again, most of the time that isn't a problem, but consider this example - say I compiled ping both to send huge pings (15 kilobytes instead of 64 bytes), and to send as many pings as possible rather than the 1 ping per second you get with normal ping. You are probably not the only person/program on your machine that uses ping. Say your GUI wifi program uses ping to check the connection with the AP you're associated with. If the code in that program says "ping $GATEWAY", it is going to use your modified ping, not the standard one. What happens when instead of sending three 64 byte pings to the AP in 3 seconds, because of your custom ping your wireless card sent four hundred 15000 byte pings in 3 seconds? Without seeing the code, you don't know what will happen. It might crash out your wifi GUI app, it might tell you that you have a great connection, or it might tell you that your connection is awful when its actually quite good. Now if the app called /bin/ping $GATEWAY instead of just ping $GATEWAY, then it would behave as it expects.

Since this is open source you could check for every call of ping on the system, and make sure they all specifically call /bin/ping if it is looking for specific results.

That shows that if you're going to custom compile something you also have installed by a package manager, you might want to give it another name. If the custom ping was named ping2, no programs would ever call ping2, unless you changed them to call ping2 explicitly.

That is also why when you're compiling software you have so many options on where libraries are located. Your system might have the libraries a program is looking for in /usr/lib, but you may have a (newer/older/compiled with different options than regular) version hiding in /usr/local/lib, or in /opt/lib, or anywhere you damn well please. The same way a golfer needs different clubs for different shots, a sysadmin may well need different libraries to get slightly different tasks accomplished.

Of course the options I described for ping don't actually need a custom compilation, you could get the size and speed modified at the command line with regular ping, I just did that for a quick example.

As to your dependency question, that's really a function of what it is that you're compiling on your own. If I compile the game "Battle for Wesnoth" on my own, it isn't going to break anything, because that is an app that sits on top of everything else. If I compile libc or some base level tool, that can and frequently will mess your whole world up. The abstract question, "is this a bad idea" is virtually worthless, particularly when you don't spell out specifically what the "this" is! That's also what made your question sound like homework, and probably what (in my opinion righteously) raised Telemachos' ire.

Peace,
JimBass

Wow JimBass, thanks for the big reply. I read over it and got a fair amount of something from it. Thanks a lot!

and yes I need to be more careful when disguising my homework (just kidding damnit!)

You might want to take a look at STOW, and/or checkinstall.