Apt dependency hell

[Neil Joseph Schelly]

On Wednesday 29 November 2006 01:56 pm, Ben Scott wrote:
>   I've been running "etch" (the current "testing") at home for the
> past few months, and that by itself has encountered dependency
> problems.  I normally wouldn't have too big a problem with that, but
> it's rather annoying that all the Debian zealots keep saying the
> problems can't possibly be happening.... :-(

It's rather annoying that someone would pigeonhole Debian zealots about saying 
things can't break in a distribution labelled "testing" - things like this 
don't happen in stable.  In testing and unstable, this is where they are 
_supposed_ to happen.

>   I thought apt-get, aptitude, synaptic, etc., were all just frontends
> to the "APT system"?

They are all wrappers of dpkg more than anything, just like yum is a wrapper 
for rpm.  They have a knowledge of where packages can be found in 
repositories and can read those repositories to find out what packages have 
what dependencies recommendations, etc.  Each program can use whatever 
algorithm it wants to try to resolve dependencies best.

The "APT System" is often a reference to the Debian system, since Debian is 
the most obvious DEB-based distribution and uses APT to manage that.  The 
fact that apt package managers like apt-get, aptitude, dselect, etc can so 
easily resolve dependencies is a measure of the reliability of the Debian 
repositories not to change things.

I was also under the impression that aptitude was intended to use the same 
algorithms as the apt-* command line tools, so that it could potentially 
replace them down the road and provide a GUI/curses interface like dselect 
all in one.
-N