#4 gnupg installer replaces /usr/local if it is a soft link

[Joseph Kiniry]

On my system, /usr/local links to a directory in
another filesystem. Everytime I install/upgrade gnupg
it deletes the link and installs its own minimal
/usr/local hierarchy containing only gnugp-related
files. This is incorrect behavior; my /usr/local
should not be touched.

[Gordon Worley]

Logged In: YES
user_id=7522

I assume by the title you are using the package installer found on
our Website and not building from source. Building from source
should respect the link, but apparently the installer does not.
I've assigned this to Alexander, who is now creating the installers
and may be able to work with you to find a solution for future
installers.

[Joseph Kiniry]

Logged In: YES
user_id=42011

Yes, I used the installer. I'm happy to work with someone
to test the correction. Thanks for quick and helpful response!

[Randall Wood]

Logged In: YES
user_id=97331

This was a known issue with Apple's Installer.app application in
Mac OS X 10.2 (Installer.app used (and may still use--I do not
know)) /bin/pax to install packages and pax overwrites symlinks
to paths it is writing to with directory entries. If I recall correctly
this behaviour is 1: undesirable and 2: compliant with the POSIX.2
standard.) I do not know if Installer.app uses a differnt tool to
extract files in Mac OS X 10.3. This may unfortunately mean that
installer packages un-symlinking your /usr/local and installing files
in a directory /usr/local is the correct behavior.

We may be able to find other workarounds. Does your symlink
point to a different physical drive than the drive / is mounted
from?

[Randall Wood]

Logged In: YES
user_id=97331

Found this note in Apple's Developer's Documentation:

By default, Installer replaces links with directories, which again is likely
to confuse (and annoy) the user, since it will orphan whatever the
symbolic link points to. In this case, the user would end up with a
Utilities directory containing just your utility, while their original Utilities
directory has been set adrift.

PackageMaker currently has no user interface option to control how
Installer handles symbolic links. However, there is a way you can change
the default behavior so that Installer follows symbolic directory links,
rather than replaces them. To do so, you edit the Info.plist file for the
package and set the value for the "IFPkgFlagFollowLinks" key to "Yes".

The URL is file:///Developer/ADC%20Reference%20Library/
documentation/DeveloperTools/Conceptual/SoftwareDistribution/
index.html#//apple_ref/doc/uid/10000145i if you installed documentation
with Xcode.

[Freek Dijkstra]

Logged In: YES
user_id=249025

Not sure if this is related.

GPG Keychain Access crashes immediately after startup if the gpg is not
located at /usr/local/bin/gpg. I had it installed at /opt/local/bin/gpg.

As soon as I created a symbolic link, everything works fine. The crash log
indicates the error is in:
Exception: EXC_BREAKPOINT (0x0006) in Thread 1
Thread 1 Crashed:
0 com.apple.Foundation 0x92901620 _NSRaiseError + 264
1 GPGME 0x18003c3c -[GPGKeyEnumerator
initForContext:searchPattern:secretKeysOnly:] + 304
2 GPGME 0x1800362c -[GPGContext
(GPGKeyManagement) keyEnumeratorForSearchPattern:secretKeysOnly:] +
116
3 ...rceforge.macgpg.GPGKeychain 0x0000fc64 -[PKOutlineDataSource
keyListWithSearchPattern:secretKeysOnly:] + 88 (PKOutlineDataSource.m:143)
4 ...rceforge.macgpg.GPGKeychain 0x0000ffa0 -[PKOutlineDataSource
doRefreshThread:] + 204 (PKOutlineDataSource.m:198)
5 com.apple.Foundation 0x928e66d4 forkThreadForFunction +
108
6 libSystem.B.dylib 0x9002b200 _pthread_body + 96

Not really enough information to determine that gpg is missing. I recommend
making a short check during start, and if gpg is not in the expected location,
give a warning before quitting.