That'd make it hidden, even for folks that don't want it to be.

Yep!
Apple's standard UI decision is to hide them, and for the very few who do not and who diverge from Apple's UI decision, you are now instead making it show for all of the (more numerous) rest who do honor Apple's UI for /opt, /private, /usr, etc. and they get this random /opt folder showing!

If you had originally honored the existing chflags setting for opt, you could check and then keep it so, but now you have revealed it for everyone.  Perhaps you can still do that , so anyone who has to keep running that command can run it once and then you can honor it going forward?  On the other hand, I'd say anyone breaking Apple's UI and showing it, knows how to get to it (and probably does) via Terminal, but I can see how that might be swinging the pendulum too far in the opposite direction...

ls -Old /opt

If not found, you should honor Apple's UI and make it hidden; otherwise, honor the existing "hidden" result of the command above (or levae it showing if "hidden" is not part of the command output.

I may have been confused.  This may just be a matter of hiding it when you create it.  I thought I was seeing this revealed on existing systems, but it should be hidden upon creation to coincide with Apple's UI expectations, as per this official guide from Apple:
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

Note the "Hidden Files and Directories: Simplifying the User Experience" section.  Although /opt is not mentioned explicitly (the list is not exhaustive, saying "Some..."), it is akin to the rest of the list of UNIX/Linux directories provided and should be hidden.

Created attachment 127326 [details]
attachment-28292-0.html

Yep!

Apple's standard UI decision is to hide them, and for the very few who do not and who diverge from Apple's UI decision, you are now instead making it show for all of the (more numerous) rest who do honor Apple's UI for /opt, /private, /usr, etc. and they get this random /opt folder showing!


If you had originally honored the existing chflags setting for opt, you could check and then keep it so, but now you have revealed it for everyone.  Perhaps you can still do that , so anyone who has to keep running that command can run it once and then you can honor it going forward?  On the other hand, I'd say anyone breaking Apple's UI and showing it, knows how to get to it (and probably does) via Terminal, but I can see how that might be swinging the pendulum too far in the opposite direction...


________________________________
From: bugzilla-daemon@freedesktop.org <bugzilla-daemon@freedesktop.org>
Sent: Saturday, October 15, 2016 6:27 PM
To: Matthew Kozak
Subject: [Bug 98273] (Re)Hide /opt on macOS on install/update


Comment # 1<https://bugs.freedesktop.org/show_bug.cgi?id=98273#c1> on bug 98273<https://bugs.freedesktop.org/show_bug.cgi?id=98273> from Jeremy Huddleston Sequoia<mailto:jeremyhu@freedesktop.org>

That'd make it hidden, even for folks that don't want it to be.

________________________________
You are receiving this mail because:

  *   You reported the bug.

Apple has no policy on showing or hiding /opt.  Apple does not ship anything in /opt and thus does not set any flags on it.  There are tons of other projects that touch /opt, and AFAIK, none of them do what you're asking.

...

And as you mention, /opt is not called out in the list of such directories.

XQuartz does not "own" /opt, so it is not up to it to change it away from the settings that the user has placed on it.  If the settings on that directory are somehow changed when this package is installed, I'd consider that a bug, but I have no idea how one would change the package to honor those settings because there is nothing in PackageMaker that reveals such an option.  If you want to provide relevant changes to our build system (including packaging), there is an open ask for such support, and I'd be glad to integrate any constructive changes you can provide.

Guess we'll agree to disagree, but it seems pretty clear that a UNIX directory like /opt falls SQUARELY in the documentation link I provided.  I'd suggest asking Apple their opinion of /opt considering it is indeed a traditional UNIX directory just like the rest they (NON-exhaustively) list as examples.

Guess we'll just keep explaining to users why /opt appears without explanation when installing XQuartz to run X-Windows apps...we've been doing it for years as it is.

(In reply to mkozak from comment #7)
> Guess we'll agree to disagree, but it seems pretty clear that a UNIX
> directory like /opt falls SQUARELY in the documentation link I provided. 
> I'd suggest asking Apple their opinion of /opt considering it is indeed a
> traditional UNIX directory just like the rest they (NON-exhaustively) list
> as examples.
> 
> Guess we'll just keep explaining to users why /opt appears without
> explanation when installing XQuartz to run X-Windows apps...we've been doing
> it for years as it is.

I've never seen a single question asked about this for XQuartz or MacPorts or any other software that installs to /opt.

That no one has noticed it or bothered to say anything is no support at all.  I don't see any documentation from Apple that would suggest the document I sent is inapplicable to /opt.  So, again, we'll agree to disagree, at least until you can get some clarity on /opt in contradiction to the link I sent?

Many thanks!

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/769.