Packaging mesos

Ryan Schmidt

2018-11-22 10:31:41 UTC

Post by David Gilman
Mesos is a ginormous C++ codebase that does distributed execution of
user tasks. I have a functioning but basic portfile here. I also have
a bunch of questions on MacPorts policy and what it will take to get a
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
PortSystem 1.0
PortGroup cxx11 1.1
name mesos
version 1.7.0
categories devel
platforms darwin
license Apache-2
homepage https://mesos.apache.org/
master_sites apache:mesos/${version}
description Apache Mesos abstracts CPU, memory, storage, and
other compute resources \
away from machines (physical or virtual), enabling
fault-tolerant \
and elastic distributed systems to easily be built
and run effectively.
long_description ${description}
checksums rmd160 28a10cb2975657034fadd0b5da6ff2b9498564d5 \
sha256
0d02700eafef0af07f2257537eb164a3fd31b6cae291e0d025335f5333acd8bf \
size 69737576
configure.args-append --with-svn=${prefix} \
--with-apr=${prefix} \
--disable-werror \
--disable-python \
--disable-java \
--disable-maintainer-mode
depends_lib port:apr-util \
port:subversion
build.env MAVEN_OPTS=-Duser.home=${workpath}/.home
I have the Java and Python libraries (APIs into mesos) disabled to
simplify the build, but it also seems that it might not be possible to
use the Python library at all because of a weird incompatibility with
modern versions of pip.
Mesos ships with many vendored 3rd party libraries. There are 21
.tar.gz files in ./3rdparty. Many of them are distributed with
macports but some have not yet been packaged. When mesos is built a
single, gigantic dylib is made that incorporates all of this code
otool -L /opt/local/bin/mesos
/opt/local/lib/libmesos-1.7.0.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.11)
/opt/local/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsasl2.dylib (compatibility version 3.0.0, current
version 3.0.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current
version 10.0.0)
/opt/local/lib/libapr-1.0.dylib (compatibility version 7.0.0, current
version 7.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
otool -L /opt/local/lib/libmesos-1.7.0.dylib
/opt/local/lib/libmesos-1.7.0.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.11)
/opt/local/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsasl2.dylib (compatibility version 3.0.0, current
version 3.0.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current
version 10.0.0)
/opt/local/lib/libapr-1.0.dylib (compatibility version 7.0.0, current
version 7.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
Is this acceptable for MacPorts, or does mesos need to be built with
MP's distribution of libraries? The mesos ./configure has options to
use local versions of these libraries: boost, concurrentqueue, elfio,
glog, gmock, grpc, http-parser, jemalloc, leveldb, libev, libevent,
libarchive, nvml, picojson, rapidjson, protobuf, sasl, ssl, stout,
zookeeper, nl. It also might be possible to ignore all vendored
package with a ./configure --disable-bundled flag and force all of the
vendored packages into MacPorts dependency handling and packaging. I
would appreciate some feedback on the MP policy here.
Finally, it seems like mesos is a little trigger happy when it comes
to installing these 3rd party libraries to the build root. I had
issues with it installing its own bundled versions of
pip/wheel/setuptools but it looks like that might be fixable. The
portfile above also installs C/C++ header files for elfio, picojson,
libprocess, rapidjson and stout alongside mesos. Is it OK for a
Portfile to do this?
For reference, Homebrew's distribution always builds with java
libraries (and has a dependency on java 1.8 or greater), it has a hack
to install the Python client library by itself and it uses the
vendored dependencies as much as possible.

Thanks for tackling a difficult port!

It's fine for a port to use bundled dependencies, especially if those dependencies are esoteric and not used by anything else. mongodb is a port where I've done this for example. There are some libraries where that is even recommended, for example boost, because boost has such a poor track record of backward compatibility: Every time we update the MacPorts boost port, tons of ports that use boost have trouble building and need patches or updates to build with that new version of boost. If a port offers a bundled copy of boost, I would highly recommend using it.

If there are switches you can use to tell this build to use MacPorts versions of some of the libraries -- and link to them dynamically (which is probably the default) -- then (with the exception of boost and any other similar libraries) that's probably a good idea for all the usual reasons (if we update a port, your port benefits from that update immediately).

I agree that ports should avoid installing bundled third-party libraries or their headers, pkg-config files, or other support files to the locations where the standalone versions of those libraries install them. Either install them to a private prefix for this port (${prefix}/libexec/${name} is a popular choice) or else create separate ports for those libraries and make this port use them instead of the bundled copies.

You could commit the port without python and java support for now if you want, then work on those later. For python support, I expect you'll want variants to let the user choose which python version. For java support, you probably want a variant since not everyone has java installed, and a user who doesn't care about the java capabilities would be annoyed at having to install java just to install the port. Though we do now have openjdk ports in MacPorts. I think we are working toward the java portgroup being able to add dependencies on those when needed, so that a user wouldn't need to manually install java first, but I don't know how far along we are with that.