Apps :: Dependency Issues with apt-get



I've been trying to install the m4, autoconf and automake packages (because they are required, in turn, to compile an application to use a Bluetooth headset) but ran across a strange problem with apt-get.

This is using DSL 3.3 rc1 and the latest dpkg.dsl with the woody archives (I did not edit sources.list). After "apt-get update" on oldstable, the m4 package installs without problems - but:

# apt-get install autoconf
...
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation:

The following packages have unmet dependencies:
 autoconf: Depends: perl (> 5.005) but it is not going to be installed
               Depends: autoconf2.13 (>= 2.13-41) but it is not going to be installed
E: Broken packages

I have seen a similar message when trying to install from testing or unstable but never from oldstable or stable.

Given that DSL has perl 5.8.0, does anybody know the reason for the error message - is it because of the way some libraries are stripped from DSL?

Note also:

# apt-get install autoconf2.13
...
 autoconf2.13: Depends: autoconf (>= 2.50) but it is not going to be installed
               Depends: perl but it is not going to be installed
               Depends: libfile-temp-perl

# apt-get install libfile-temp-perl
...
 perl-modules: Depends: perl (>= 5.6.1-1) but it is not going to be installed

# apt-get install automake        
...
 automake: Depends: autoconf but it is not going to be installed

I got those errors all the time using apt with DSL.  Debian Woody of course does not have Perl 5.8.  It only has up to version 5.6, so I reckon apt does not even know that the installation of Perl 5.8 exists.  As you know, DSL is based on Debian Woody but also has a lot added that basically breaks the apt system in many situations.  Makes it hard to meet dependencies to compile programs, though there are ways around it.  I basically started treating DSL as if I were using Slackware and don't even use apt much at all and manually install stuff instead.  Life has been much easier since.
Quote (Jason W @ Mar. 04 2007,22:49)
I basically started treating DSL as if I were using Slackware and don't even use apt much at all and manually install stuff instead. Life has been much easier since.

Well...maybe.

Although this often works, I sometimes have difficultly to find a .tar.gz package of the right "vintage" to install easily and occasionally cannot find the package at all.

To make things easy for me, I tend to do most of my compiling for DSL on Debian Woody, which I also use as my HD install system.  The resulting packages can usually be plugged right in to DSL or even Debian Sarge since older packages seem to work on newer systems, but not the other way around.  In Woody, I can have -dev packages installed coming out my ears making it much easier to work with than trying to compile things for DSL, which by it's very nature makes it hard to have the right -dev packages installed due to it's design.  If I must compile on DSL, I sometimes have to grab packages from Woody and install them with dpkg, even having to do a dpkg --force-all -i pkgname.deb at times.  I am not very experienced on compiling on DSL since I quickly fell into the dependency issues that made me run back to Woody to do my compiling.  Sure, I took the easy way out, but I am learning more about the DSL development system.
 There is the occasional dependency issue that you will run into when compiling on Woody for DSL since DSL has some updated and different packages but that is the exception and not the rule.  Now for kernel stuff, one of course must use DSL or install the specific kernel stuff on another system.  Hope this made some sense.

For autoconf, automake, m4, libtool, and other gnu tools, I have always downloaded it and built it from source (watch out for the many different versions, though!).
Next Page...
original here.