Packaging mesos

David Gilman davidgilman1 at gmail.com
Mon Nov 19 16:59:06 UTC 2018


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
mesos port accepted.  Here is my portfile:

# -*- 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
maintainers         {@dgilman gilslotd.com:dgilman} openmaintainer
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
(none of these libraries are shipped with mesos):

otool -L /opt/local/bin/mesos
/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:
/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.

-- 
David Gilman
:DG<


More information about the macports-dev mailing list