Re: Moving files out of PREFIX on macOS

[ivan%ivanpollak.com@localhost]

September 30, 2026 at 12:16 PM, "Greg Troxel" <gdt%lexort.com@localhost mailto:gdt%lexort.com@localhost?to=%22Greg%20Troxel%22%20%3Cgdt%40lexort.com%3E > wrote:


> 
> ivan%ivanpollak.com@localhost mailto:ivan%ivanpollak.com@localhost  writes:
> 
> > 
> > Im encountering an issue that I would like to solve on the macOS platform -- When
> >  installing a GUI application, for example x11/alacritty, it will place the .app file
> >  into ${PREFIX}/Applications, which is correct, however macOS doesn't provide any way
> >  to adjust where the system searches for the installed applications. All GUI programs,
> >  e.g. .app files (actually they are directories but anyways) need to live in
> >  /Applications to be found by launchpad and since macOS 26 the spotlight application
> >  section.
> > 
> >  The same happens with fonts. MacOS only searches through /Library/Fonts/ for installed
> >  fonts. I haven't tested it, but it is possible that ~/Library/Fonts/ also is searched
> >  as well as ~/Applications/. This creates a major issue and for every GUI application or
> >  font, some files need to be either symlinked or moved. (Fonts cannot be symlinked, .app
> >  files can)
> > 
> >  Has anyone already solved this issue? I've heard that using the INSTALL/DEINSTALL could
> >  be used. Would this actually be feasable in this situation?
> > 
> INSTALL and DEINSTALL don't really seem appropriate for putting things
> outside of $PREFIX.
> 
> You are running into a core doctrinal issue in pkgsrc, that it builds to
> $PREFIX, and a base system that is deficient in configurability. There
> was a lot of angst about mozilla-rootcerts-openssl which put things into
> the system openssl directory, and it was considered a necessary evil but
> my impression was that nobody was really happy about it even though most
> agreed it was better to have it than not have it. It was banned as a
> dependency, though.
> 
> There is another issue, that I brought up long ago and got ~no
> responses: on macOS, one can build many GUI two ways:
> 
>  - using X, as if the mac were a normal unix computer
>  - using mac frameworks, making a .App
> 
> We don't really have a coherent plan as to which we want to do, and the
> set of upstreams are not entirely coherent either. While .App is in
> some ways nicer, you can't run it over remote X11, so in that way it's
> deficient.
> 
> I would suggest:
> 
>  If you want what you do to end up as part of pkgsrc, instead of just
>  being your private mechanism, do not include LLM output.
> 
>  First, survey homebrew, macports, and fink, plus any other mac-centric
>  packaging system that exists or existed, and see what they do about
>  this issue. Find out why, and what problems they had.
> 
>  Think about shlib linking, and the consequences of moving bits from a
>  .app in $PREFIX to Applications. Which libs are loaded from where.
>  This is going to cause you to have to really under libraries and
>  dynamic linking on macOS, which seems to be much more complicated than
>  on a normal (ELF) computer.
> 
>  Consider a tool to do a mac-ish installation of some bits of a pkgsrc
>  pkg, probably symlinking *.App and copying fonts, with registration,
>  and of course uninstall. Use that with packages from pgksrc to hook
>  them into the mac world. Probably publish that tool and make a
>  package.
> 
>  Given the above tool, it would be a reasonable discussion about a way
>  to hook it into package installation/deinstallation as an
>  after-install pre-deinstall slot. I mean to add a feature to call
>  hooks to pkgsrc, not to accomodate mac stuff specifically.
> 
> That's all opinionated and I only thought about it for 5 minutes. The
> most important thing is to understand related work first.
>

Thanks for your input!

According to the documentation it is officially recommended to use
INSTALL/DEINSTALL to handle cases where files should go outside of
the ${PREFIX}. [1]

Also im pretty sure that .App's would be the preferred way of building
and installing packages due to them being integrated with the base system