Re: pkgsrc-2013Q4 Circular dependencies

[Tim Hawes <tim%easyfreeunix.com@localhost>]

Here is the output for bmake show-depends-pkgpaths. First for python27,
which was the initial package I showed the output for, and secondly for xz

[root@centos5 python27]# bmake show-depends-pkgpaths
archivers/bzip2
archivers/xz
databases/db4
devel/gettext-lib
devel/libffi
devel/nbpatch
devel/readline
devel/zlib
pkgtools/digest
security/openssl
[root@centos5 python27]# cd ../../archivers/xz
[root@centos5 xz]# bmake show-depends-pkgpaths
devel/gettext-lib
devel/libtool-base
pkgtools/digest
[root@centos5 xz]#

It might also be worth mentioning that both machines are xen virtual
machines on a CentOS 6 host. I had downloaded pkgsrc-2013Q4 on to the
Xen Dom0 host, with the two virtual machines mounting the pkgsrc
directory on the Dom0 via read-only NFS. Thinking the issue might be nfs
related, I downloaded the 2013Q4 sources for the Centos 5 machine and
re-did the bootstrap. You'll see I am sending the output from the
non-nfs Centos 5 box (obvious PS1 prompt with the hostname).

I am tempted to try a "yum groupinstall Base" on the Centos 5 instance to
see if this makes any difference. That's what I had done in the past
when I got the older 2013Q2 sources building. I just want to understand
why it does not work as it is.


gdt%ir.bbn.com@localhost writes:

> It looks like the build of xz is somehow inheriting the notion that it
> needs xz from the parent.  You may find "bmake show-depends-pkgpaths" to
> be helpful in figuring out why xz thinks it needs itself.
>
> But, if you can build and install xz itself, that's a functional
> workaround, even though something's wrong.
>
> (I've seen a problem with ccache and I think checkperms, but that only
> happens when one puts ccache in PKGSRC_COMPILER.)

-- 
Sent with my mu4e