font ports?

[Rainer Müller]

On 2015-11-30 09:58, Andrea D'Amore wrote:
> On 30 November 2015 at 06:01, Ryan Schmidt <ryandesign at 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