dependency lookup failures

Panu Matilainen pmatilai at laiskiainen.org
Sat Apr 28 12:12:31 PDT 2007


On Fri, 27 Apr 2007, Vincent Danen wrote:

> I just saw something interesting:
>
> [vdanen at build ~]$ apt-get build-dep subversion-1.4.3-7277avx.src.rpm Reading 
> Package Lists... Done
> Building Dependency Tree... Done
> Selecting lib64python2.4-devel for 'python-devel'
> E: Build-Depends dependency for subversion-1.4.3-7277avx.src.rpm cannot be 
> satisfied because no available versions of package neon-devel can satisfy 
> version requirements
> [vdanen at build ~]$ apt-get install neon-devel
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Selecting lib64neon0.24-devel for 'neon-devel'
> The following NEW packages will be installed:
> lib64neon0.24-devel
> 0 upgraded, 1 newly installed, 0 removed and 0 not upgraded.
> Need to get 76.5kB of archives.
> After unpacking 130kB of additional disk space will be used.
> Get:1 ftp://build.annvix.ca x86_64/current lib64neon0.24-devel 0.24.7-6638avx 
> [76.5kB]
> Fetched 76.5kB in 0s (2224kB/s)       Committing changes...
> Preparing...                ########################################### 
> [100%]
>  1:lib64neon0.24-devel    ########################################### [100%]
> Done.
>
>
>
> Why is this happening?  Obviously apt-get is smart enough when called by
> "install" to know what package to install, but not when called by
> "build-dep".  Is there a reason for this?  It doesn't happen often, but
> I've noticed it once or twice.

A long-standing, known issue: build-dep operation isn't very smart when 
it comes to dependencies on virtual provides (as opposed to direct package 
names), especially when versions are involved.

That's one item on my neverending apt-rpm todo-list :)

 	- Panu -



More information about the Apt-Rpm mailing list