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