Add DESTDIR and PREFIX capabilities for packaged installs

[essandess]

I've ported Apple Calendar and Contacts Server to MacPorts. See https://github.com/macports/macports-ports/pull/4978

ccs-calendarserver does not provide a standard GNU-like/compliant DESTDIR capability for staged installs.

1. PREFIX (or --prefix) tells the compiler to build everything for the ultimate destination.
2. DESTDIR tells the compiler to install its builds in this (typically temporary, staged) location.

A package manager like MacPorts or Brew can then copy everything from DESTDIR to PREFIX, or archive everything in DESTDIR, to track and control what’s been installed, and how to uninstall or upgrade.

Without both DESTDIR and PREFIX options, there’s no reliable way for the package manager to manage its packages. E.g. see MacPorts’s destroot stage in https://guide.macports.org/chunked/reference.phases.html.

Sometime it’s possible to hack around this limitation (calendar-contacts-server example, ihaskell example), but it’s pretty awful. There is rudimentary --prefix capability in _build.sh, but this doesn't work like a standard package PREFIX or --prefix does.

In my own tests, running ./bin/package -F ${DESTDIR} hard codes the build directory within all the virtualenv compiled Python code and object libraries, and therefore does not work. Even hacky workarounds like creating symbolic links to DESTDIR and building within the symlinks don't work.

Now that Server.app has deprecated Calendar and Contacts Server to open source projects, the only reasonable approach is using a package manager like MacPorts to handle installs and upgrades, and that means having DESTDIR and PREFIX capabilities.

[essandess]

@dreness @wsanchez @cyrusdaboo @m0rgen @glyph

Also, if any of you have specific comments or suggestions about how https://github.com/macports/macports-ports/pull/4978 is implemented, your feedback would be most welcome.

I have this running myself, and it's working very well. Known issues are mentioned in port notes calendar-contacts-server:

• All local accounts have access to calendarserver's password using

  security find-generic-password -a calendarserver@${fullhost} -g

  This is a hack to provide twistedcaldav authentication access. See: https://github.com/apple/ccs-calendarserver/blob/master/twistedcaldav/util.py. An alternate approach must be used if non-trusted local accounts exist on the Calendar and Contacts Server.

• There is no destroot capability in ccs-calendarserver (this issue).
• The exisiting Portfile implementation uses native macOS Python, not MacPorts Python. It's not clear yet how macOS will handle Python 2.7 after its EOL.
• The package ccs-calendarserver is written in Python 2.7, which will reach the end of its life on January 1st, 2020. A future version of pip will drop support for Python 2.7.

[dreness]

Hi,

In my own tests, running ./bin/package -F ${DESTDIR} hard codes the build directory within all the virtualenv compiled Python code and object libraries, and therefore does not work. Even hacky workarounds like creating symbolic links to DESTDIR and building within the symlinks don't work.

Hmm... the intention for ./bin/package is to provide a fully coherent and localized installation at the desired path. The supplied path is indeed encoded in various places within the results. I'm not doubting that you're finding a bug, though... Are the results any different if you build first (i.e. ./bin/develop) and then ./bin/package, without -F? In theory there should be no difference, but maybe there is.

Also, kudos on your work for this port, and all the related efforts. I'll try to find some time to do a more thorough review.

[essandess]

@dreness Thank you for your pointers here and elsewhere.

I’ll give your suggestion a go.

I realize this isn’t a bug, but it is an “undesirable feature.”

At the least, it would be nice to be able to hack around it with some temporarily created symlinks during the build, but for some reason the build scripts are seeing through those.

[essandess]

@dreness Thanks for the suggestion, but that still doesn't work:

./bin/develop
mkdir /path/to/destdir
ln -s /path/to/destdir /prefix/path/to/install
./bin/package /prefix/path/to/install
rm /prefix/path/to/install

This find for /path/to/destdir should turn up nothing (because the package was sent to /prefix/path/to/install), but lot and lots of compiled Python code and shared objects have hard links to /path/to/destdir:

find /path/to/destdir -type f -exec fgrep /path/to/destdir -- {} /dev/null ';' | grep -v log