BUG: openssl-0.9.7e_0

[paulbeard@…]

white:~ paul$ sudo port -vvf install openssl ---> Installing openssl 0.9.7e_0 ---> Activating openssl 0.9.7e_0 <serious snippage> Error: Target com.apple.activate returned: could not read "/opt/local/share/man/man3/SSL.3.gz": no such file or directory Warning: the following items did not execute (for openssl): com.apple.activate

How to resolve this? For what it's worth, openssl seems to install from source without this problem.

And as a workaround how can I either a. tell ports not to use openssl as a dependency or b. tell the ports system it's installed so it quits griping at me.

[ssen@…]

are you building on UFS but installing to HFS+?

[paulbeard@…]

That's right. I don't recall if this started when I switched to mounting the tree versus keeping it local.

If I can free up the space, I'll try recreating a ports tree locally and building/installing from that.

[paulbeard@…]

So this is caused or provoked by the "build on UFS, install on HFS+" regime I have been using. A new ports tree, stored locally, works just fine.

That seems backwards to me: I wouldn't have thought the filesystem where something was built made any difference to where it was installed.

I'm reluctant to call this resolved, as I'm sure I won't be the only person to centralize a ports repository rather than keep it local on every system.

[ssen@…]

Of course it makes a difference.

The question is where the bug is. If OpenSSL has case collisions, that should probably be fixed.

[mww@…]

does our openssl port version 0.9.8 still misbehave?

[paulbeard@…]

(In reply to comment #5)

does our openssl port version 0.9.8 still misbehave?

I haven't had occasion to check: I switched the way I manage ports to use a local filesystem. Am I the only person to ever attempt this?

;-)

[mww@…]

I hereby declare this problem to be esoteric! =)