On 2015-11-30 09:58, Andrea D'Amore wrote: > On 30 November 2015 at 06:01, Ryan Schmidt <ryandes...@macports.org> wrote: >> /Library/Fonts is a location which users expect to be in control of. They >> expect to be able to install and uninstall files here, and not to have files >> there owned by MacPorts or other software. > > I disagree with the reasoning here, the ability of installing and > uninstalling files from a path doesn't depend on the presence of > mp-owned files, with the obvious exception of an already taken file > path. > >> What would happen if the user had already installed the font there, and then >> MacPorts tried to install it there? (MacPorts would fail with an activation >> error.) >> What would happen if the user tried to remove the font MacPorts installed >> there by dragging it to the trash? (The Finder would say they are not >> authorized to do that.) >> What would happen if the user's MacPorts registry becomes corrupted somehow >> and they have to follow the emergency uninstallation instructions? (These >> font files would not be uninstalled, because they were not installed in a >> directory MacPorts owns.) > > The same things that would happen if, say, I manually copy > TextEdit.app as /Applications/MacPorts/MacVim.app and then try to > install the macvim port. The other two scenarios can happen even more > easily without explicit trickery.
Here we have the explicit /Applications/MacPorts/ we claim to have control over. It is unlikely anyone would put an application there without using MacPorts. >> For these reasons, I would say no, you should not write a port that installs >> anything in /Library/Fonts. I'm not aware of any existing ports that do that. > > Not for fonts, but there are standardized exceptions to writing in > $prefix, applications_dir and daemons/agents' plist files. > This is an use case of the same kind of the applications one, only > with a different target. > > As it turns out the system (or Cocoa at least) recursively scan the > font folders, so adding system-wide port fonts in > /Library/Fonts/MacPorts doesn't seem anything different that what's > already being done. If it is possible to use something like /Library/Fonts/MacPorts/ we could use it. On a side note, if I put a font file in both /Library/Fonts/ and /Library/Fonts/MacPorts/, which will take precedence? However, using such a path would need the same treatment as applications_dir and frameworks_dir in base, especially for binary archives and to support multiple co-existing installations of MacPorts on the same machine. > Think for example of a port that is just a collection of fonts without > a standalone application, how would you install that and then tell > your regular Cocoa apps about the fonts? Is there really a need to manage fonts with MacPorts? Could you provide a use case or example port? Also, do the fonts in question allow redistribution in their license? Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
