Open essandess opened 5 years ago
@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
:
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.
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 toDESTDIR
and building within the symlinks don't work.
Hmm... the intention for ./bin/package
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.
@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.
@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
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.PREFIX
(or--prefix
) tells the compiler to build everything for the ultimate destination.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
toPREFIX
, or archive everything inDESTDIR
, to track and control what’s been installed, and how to uninstall or upgrade.Without both
DESTDIR
andPREFIX
options, there’s no reliable way for the package manager to manage its packages. E.g. see MacPorts’sdestroot
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 packagePREFIX
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 toDESTDIR
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
andPREFIX
capabilities.