Packaging mesos

[Ryan Schmidt]

On Nov 19, 2018, at 10:59, David Gilman wrote:

> 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.

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.