Can not remove the new MacPorts Mojave package

[Ryan Schmidt]

On Nov 9, 2018, at 10:36, Dr M J Carter wrote:
> On Fri, Nov 09, 2018 at 04:05:34PM +0100, Vincent Habchi wrote:
>> On 9 Nov 2018, at 11:31, Dr M J Carter wrote:
>>> 
>>> On Wed, Oct 03, 2018 at 01:25:28PM +0100, Chris Jones wrote:
>>>> On 03/10/18 13:16, S. L. Garwood via macports-users wrote:
>>>>> I installed the new Macports bundle mentioned in Josha Root’s email.
>>>>> Install went fine, but now it will not uninstall — doing the “rm”
>>>>> commands in /opt/local gets a series of errors
>>>>> 
>>>>> rm: /opt/local/var/macports/home/Library/Preferences: Operation not
>>>>> permitted
>>>>> rm: /opt/local/var/macports/home/Library: Operation not permitted
>>>>> rm: /opt/local/var/macports/home: Operation not permitted
>>>>> rm: /opt/local/var/macports: Directory not empty
>>>>> rm: /opt/local/var: Directory not empty
>>>>> rm: /opt/local: Directory not empty
>> 
> 
>> Did you check the script was executed with root privilege?
> 
> Info from current tests (not yet completed): "whoami" just before the
> removal yields "root" under all conditions.
> 
>> Also what
>> files are left in /opt/local/var/macports/home/Library/Preferences?
> 
> Completely empty; no fancy permissions either afaict.  But by the time
> I get to check them, the rm would succeed, so that probably doesn't
> tell us much.
> 
>> Any hard link to any other file that could be protected by a sandbox
>> mechanism?
> 
> No hard links that I spotted (but would that not fail under 10.13? the
> same code runs fine).  The only differences between what fails and
> what works are 10.14 vs 10.13 and older, and [sound effect: penny
> dropping] APFS vs HFS+ journaled.  If there's some protection going
> on, it seems to be of macports's home dir, as the errors change to
> "directory not empty" for that dir's parent.
> 
> Hope this helps.  More information next week, once the build system
> has tried to do a build unattended twice in succession, this time with
> exponential backoff between removal attempts.  Suggestions for extra
> checks to add into the runtime scripting welcomed .... as you might
> gather, this one really has got under my fingernails.  Apologies for
> any fallout.

Since it sounds like you have some kind of Heisenbug that disappears under later analysis, I'd suggest adding any analysis you can to the script you're running when it fails.

For example, have the script use `find` to show all the files remaining in /opt/local after the script fails to delete it. If you're root, you should be able to delete anything, so it's not permissions. It's not System Integrity Protection (SIP) either; that applies to files Apple provides with the OS, which does not include MacPorts.

You could also have the script run `lsof | grep /opt/local` to see what files in /opt/local/are still open at the time of the failure. The only file MacPorts always copies into its home directory is the Xcode preferences plist. On Mojave you're using Xcode 10, which is of course different from Xcode 9 and earlier. One big change is that the "new build system" is used by default. Since it is not as well tested as the old build system, it may still have bugs. Maybe it is holding the preferences file open where the old build system did not.

Xcode also loves to spawn its simulator service, even though, as far as I know, MacPorts doesn't make use of it. Maybe the simulator service in Xcode 10 is doing things with the preferences directory that it did not on previous versions. You might even investigate having your build script kill the simulator service (com.apple.CoreSimulator.CoreSimulatorService) to see if that clears up the problem.

I'm not aware of any changes in MacPorts specific to Mojave that would relate to the handling of the home directory. So I think the bug you're investigating is a bug in macOS or Xcode, not MacPorts.