Re: Moving files out of PREFIX on macOS

[Greg Troxel <gdt%lexort.com@localhost>]

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.