font ports?

[Andrea D'Amore]

On 30 November 2015 at 10:53, Rainer Müller <raimue at macports.org> wrote:
> 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.
[…]
> 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.

In fact that's what I was thinking, adding support for something like fonts_dir.

As much as mp wants to live in $prefix on its own there are
unavoidable point of contacts with the system.

I think this "fonts_dir" is just a new kind of these macports-system
"contact point" that could be implemented.
I cannot imagine other ones right now but the thing about the future
is that we don't know what will pop up, the same way fonts_dir wasn't
seen as necessary when support for applications_dir was added.

We could abstract one level higher and have a
"contact_point_with_system" list  (help me with proper naming there),
e.g. {applications framework fonts}, and then add the relevant
{$point}_dir and install phase variables for deploying content in
them.

> 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?

Not that i know, it was just a theoretical port for making my point.
But assuming licensing is fine it's not really different than a
documentation-only port like man-pages-posix, the difference is how
it's accessed since man(1) has expicit support for reading paths from
environment while fonts don't.


-- 
Andrea