py26-gtk upgrade wants to install atlas (due to dependency on py26-numpy)

[vinc17@…]

When I want to upgrade py26-gtk, I get:

$ sudo port -v upgrade py26-gtk
Warning: Skipping upgrade since openssl 0.9.8k_0 >= openssl 0.9.8k_0, even though installed variants "" do not match "+darwin". Use 'upgrade --enforce-variants' to switch to the requested variants.
Warning: Skipping upgrade since help2man 1.36.4_1 >= help2man 1.36.4_1, even though installed variants "+darwin_8" do not match "". Use 'upgrade --enforce-variants' to switch to the requested variants.
Warning: Skipping upgrade since fftw-3 3.2.2_0 >= fftw-3 3.2.2_0, even though installed variants "" do not match "+powerpc". Use 'upgrade --enforce-variants' to switch to the requested variants.
Warning: Skipping upgrade since gmp 4.3.1_1 >= gmp 4.3.1_1, even though installed variants "+universal" do not match "+powerpc+universal". Use 'upgrade --enforce-variants' to switch to the requested variants.
Warning: Skipping upgrade since gzip 1.3.12_0 >= gzip 1.3.12_0, even though installed variants "+darwin_8" do not match "". Use 'upgrade --enforce-variants' to switch to the requested variants.
--->  Computing dependencies for atlas.
--->  Configuring atlas
[...]

There's no reason why atlas should be installed:

Full Name: py26-gtk @2.16.0
Library Dependencies: python26, atk, gtk2, libglade2, py26-cairo, py26-gobject

With the -d option, I get:

[...]
DEBUG: Found port in file:///Users/vinc17/software/dports/python/py26-setuptools
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: py26-setuptools 0.6c11_0 exists in the ports tree
DEBUG: py26-setuptools 0.6c11_0  is the latest installed
DEBUG: py26-setuptools 0.6c11_0  is active
DEBUG: Merging existing variants  into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: /Users/vinc17/software/dports/python/py26-setuptools
DEBUG: OS Platform: darwin
DEBUG: OS Version: 8.11.0
DEBUG: Mac OS X Version: 10.4
DEBUG: System Arch: powerpc
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Using group file /Users/vinc17/software/dports/_resources/port1.0/group/python26-1.0.tcl
DEBUG: not using configure, so not adding the default universal variant
DEBUG: Requested variant powerpc is not provided by port py26-setuptools.
DEBUG: Requested variant darwin is not provided by port py26-setuptools.
DEBUG: Requested variant macosx is not provided by port py26-setuptools.
DEBUG: No need to upgrade! py26-setuptools 0.6c11_0 >= py26-setuptools 0.6c11_0
DEBUG: No need to upgrade! py26-nose 0.11.1_0 >= py26-nose 0.11.1_0
DEBUG: Found port in file:///Users/vinc17/software/dports/math/atlas
DEBUG: atlas is *not* installed by MacPorts
DEBUG: Searching for dependency: atlas
DEBUG: Didn't find receipt, going to depspec regex for: atlas
DEBUG: Changing to port directory: /Users/vinc17/software/dports/math/atlas
[...]

The word "atlas" doesn't occur before.

[vinc17@…]

Hmm... it seems the cause is that py26-cairo depends on py26-numpy, which now depends on atlas (added in r59608). I think that when adding dependencies, the revision should be increased to avoid such problems.

BTW, is the dependency on atlas really necessary? py26-numpy built fine before r59608.

[skymoo (Adam Mercer)]

Cc Me!

[jameskyle@…]

My understanding is that you're requesting that atlas be removed as a dependency.

Whether to include atlas as a dependency and the pros and cons to doing so were discussed at length in the mailing list before the change was made. That archive can be viewed here: ​http://lists.macosforge.org/pipermail/macports-dev/2009-October/010313.html

Short story is:

• It's macport's policy to link against our own libraries when possible
• The apple lapack/blas implementation is incomplete and some programs fail compiling against them.
• When two applications cross link, one with apple blas/lapack and one with standard blas/lapack as provided by macports bad things like segfaults and application crashing can happen.

There are already steps you can take if you're dead set on not installing the standard blas/lapack package.

• You can either exclude it all together in variants.conf with entries such as +no_atlas.
• You can build the packages you wish to exclude atlas form with their corresponding variants.

[jmroot (Joshua Root)]

He's right that the revision should have been bumped when the dependency was added, though.

[vinc17@…]

Replying to jameskyle@…:

My understanding is that you're requesting that atlas be removed as a dependency.

No, this was just a question. The problem is that atlas is built while py26-numpy does not use it (you need to increase the revision for that).

Short story is:

• It's macport's policy to link against our own libraries when possible
• The apple lapack/blas implementation is incomplete and some programs fail compiling against them.

I didn't know that Apple's implementation was used. How can this be detected, e.g. with otool?

[jameskyle@…]

yes, otool is a good way, e.g.

otool -L /path/to/library.dylib