BUG: .mpkg installer stomps on symlink /opt

[nxg (Norman Gray)]

Actual behaviour: I installed emacs-22.0.50.1.mpkg (though I imagine the problem is common to other similar .mpkg's), on a system which had /opt symlinked to another directory. The installation script replaced this with a new directory /opt. It didn't stomp on the contents of the symlinked directory (thank heavens). This is not good -- it doesn't destroy anything, but it's a hassle to sort out.

Expected behaviour: installer recognises that an /opt which is symlinked to another directory is OK.

I've categorised this as a `dports' bug, but I'm not sure if that's correct.

[mww@…]

assign to master of mpkg/blame Jordan

[danielluke (Daniel J. Luke)]

Isn't this just how .pkgs work? (or more specifically the cpio/pax archives inside of the .pkgs)?

At least, it used to work this way:

​http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html

[nxg (Norman Gray)]

Argh! I remember that from 10.0 -- I'm a bit dismayed that it's still the case. The POSIX pax definition <​http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html> does include quite a number of references to both archiving and extracting hard and soft links (it used to be that POSIX/pax didn't acknowledge symlinks at all, didn't it?), but in a fairly quick read through this it doesn't specifically mention traversing symlinks on the way to the location of an extracted archive.

In the POSIX General Concepts' section, however, there is this text: If a symbolic link is encountered during pathname resolution, [and the symlink is to be traversed], the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. [T]he resolved pathname shall be the resolution of the pathname just created.' By stomping on symlinks, the OS X pax appears not to conform with this, and thus it seems that it simply doesn't comply with the current standard [1]. I know that Darwin doesn't claim to be a UNIX(R); it still makes it a legitimate request, on the boundary between enhancement request and bugreport, that Darwin's pax do a more reasonable thing, here. I also know that Apple have in the past been resistant to changing this behaviour (as the stepwise.com link above remarked) -- is it worth trying again, do you think?

That doesn't stop the installer's behaviour being broken; it just makes fixing it problematic. Does the installer _necessarily_ use pax, with no option of telling it to use (gnu)tar instead? That would be safe from one point of view, since (is this correct?) gnutar is as reliably present as pax.

Changing the behaviour so that the installer respects symlinks would be a theoretically incompatible change. I can't imagine that it would cause any problems in fact.

Is there any point in the .mpkg setup that it can check whether any of the elements in the installation path are symlinks? If it could at least warn about this, that would be better than nothing; and if the warning pointed to some workaround page on opendarwin.org that would be even better.

All the best,

Norman

[1] I've been saying POSIX' above, rather informally. I'm reading and quoting Single Unix version 3', which is identical with IEEE Std 1003.1-2001, which is a revision of IEEE Std 1003.2-1992 (POSIX-2). See <​http://www.unix.org/version3/ieee_std.html>. This, by the way, is the standard that the UNIX trademark refers to.

[nxg (Norman Gray)]

I reported this as a pax/Installer bug in Apple's bugreporter, where it has Bug ID 4179105. Us profane outsiders can't see such bugs in general, of course. I can still see it, though, so should be able to report on what status it gets.

[nxg (Norman Gray)]

The bug was closed with status `Behaves correctly', but without more detailed rationale. Grrr.

However, on the bright side, the engineer who assessed it -- one Stoney Gamble -- helpfully mentioned that `If the flag "IFPkgFlagFollowLinks" is set to true, then the installer will follow the link [...]'. Googling, I discover <​http://developer.apple.com/documentation/DeveloperTools/Conceptual/ SoftwareDistribution/Concepts/sd_pkg_flags.html>, which documents this package plist flag as apparently doing just the right thing, and points to <​http://developer.apple.com/documentation/ DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_permissions_author.html#apple_ref/ doc/uid/20001769-1029386-CFAHBFHC>, which says `By default, Installer replaces links with directories, which again is likely to confuse (and annoy) the user' -- well, isn't that just the truth!

Does this mean that this stomping behaviour (which I _still_ see as broken, dammit) can be fixed within opendarwin packages at least, by setting this flag to true?

Incidentally, I've created a feature request (Apple Problem ID 4183635) asking that it be possible for an administrator to set the default for this:

[...]The language in the second document above effectively suggests that the default (flag off) is the counter-intuitive behaviour, since it more-or-less advises that this flag be set on for any packages one creates.

So the feature request is that, contrary to the document above, you give a machine's administrator some option to control Installer's behaviour here -- effectively having this IFPkgFlagFollowLinks flag default on or (as at present) off for all installations. Given the sort of feature this is, and given the users who would want to use it, I imagine this needn't be a GUI option, but could be expressed through the defaults' system: defaults read com.apple.installer' doesn't show anything likely at present, and there's no mention of anything obviously relevant in the 'installer' manpage.

[saha@…]

This Darwin port package shows up a /opt file once the computer is reloaded. I found an alternative installer from another source that I felt was cleaner.

​http://www.apple.com/downloads/macosx/development_tools/emacsforosx.html

[olegb@…]

Since this are old pkgs, and also a bug not in darwinports - closing.