caminoix,

>>
staying away from command line is certainly helpful. it's not that i'm very much against it, but it might really be discouraging for a complete newbie just like me
>>

In Aus, the tourist industry have a jingle for holidaying in the top end. What we call the 'never never' ...

"You'll never never know, if you never nerver go" (grin) (i couldn't resist that one)


Command lines and source compiles. Keep it simple, experiment with very small programs, in order to get an initial feel.


>>
just one question more: what do i do if installing from source fails 'cause i don't know where to find files it says it needs or it doesn't say what files it needs,
>>

Learn by doing ...
Post the erro here ...
pipe the output to a log ... ie;

]$ make 2>&1 | tee logfile

Then just start with the first error first. Sometimes, pasting a whole error output string on a google search will return info on that particular error. Lots of errors can be missleading, as often those that follow are just leading on from the previous. That is, if you can solve the initial ones, often the layer will disapear. And like all things, it's just something that needs to be done in practice.


Some Common Error Trivia:
-----------------------------------------

"carn't find symbole"

often it is trying to link with an incompatible library version. it probably wonts a later version.


"compiler can't create executables"

look for a typo in the configure script, look into the config.log file, backing through it to anything to do with the linking stage of a test compile. There is likely a missing space between two cli switches concerned with the linking.


"carn't find libblah"

your probably trying to compile Qt (couldn't resist that one either )


>>
and finally dpkg -i only gets me an installed and uncompressed but uncompiled source?
>>

The switch is for "installing" a binary package. Not unpacking source. Look into your manuals, including "dpkg-deb".

The "--dry-run" switch can be handy for doing dummy runs, just to extract info.

dpkgmay not have a direct "what-depends" switch, as does the "rpm" system, but ...

"--dry-run -r <packagename>" and
"--dry-run -P <packagename>"

will safely tell you what is dependent on that package.


jm