[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#760315: ITP: apache-mesos -- Cluster manager for sharing distributed application frameworks



On 02.10.2016 01:34, Daniel Stender wrote:
> I've now spend a couple of hours working on packaging Mesos 1.0.1. There are several problems
> using Debian packages instead of the libraries vendored/bundled in 3rdparty/.
> 
> The config system provides switches like --with-boost, --with-gmock, --with-glock etc., but:
> 
> 1) for Boost they developers are using "-isystem" instead of "-I" imports for the CPPFLAGS
> to easily overcome some problems (https://issues.apache.org/jira/browse/MESOS-3932), but
> -isystem makes problems for the other imports:
> 
> <buildlog>
> {...} -c gmock_sources.cc  -fPIC -DPIC -o .libs/libgmock_la-gmock_sources.o
> In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
>                  from /usr/include/c++/6/bits/basic_string.h:5402,
>                  from /usr/include/c++/6/string:52,
>                  from /usr/include/c++/6/bits/locale_classes.h:40,
>                  from /usr/include/c++/6/bits/ios_base.h:41,
>                  from /usr/include/c++/6/ios:42,
>                  from /usr/include/c++/6/ostream:38,
>                  from gmock-1.7.0/gtest/include/gtest/gtest.h:55,
>                  from gmock-1.7.0/gtest/src/gtest-all.cc:39,
>                  from gmock_sources.cc:18:
> /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
> </buildlog>
> 
> see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 (stdlib.h: No such file or directory when using -isystem /usr/... )
> 
> 2) the gmock import paths are not working out of the box with the google-gmock package:
> 
> --with-gmock=/usr:
> 
> <buildlog>
> checking gmock-all.cc usability... no
> checking gmock-all.cc presence... no
> checking for gmock-all.cc... no
> configure: error: cannot find gmock
> -------------------------------------------------------------------
> You have requested the use of a non-bundled gmock but no suitable
> gmock could be found.
> </buildlog>
> 
> it should be going something like:
> 
> <diff>
> --- a/configure.ac
> +++ b/configure.ac
> @@ -808,12 +808,12 @@ AM_CONDITIONAL([WITH_BUNDLED_GLOG],
>                 [test "x$with_bundled_glog" = "xyes"])
>   
> -GMOCKSRC="gmock-all.cc"
> +GMOCKSRC="src/gmock-all.cc"
>  GTESTSRC="gtest-all.cc"
>  
>  if test -n "`echo $with_gmock`"; then
>    CPPFLAGS="$CPPFLAGS -I${with_gmock} -I${with_gmock}/include \
> -    -I${with_gmock}/src -I${with_gmock}/gtest -I${with_gmock}/gtest/include \
> +    -I${with_gmock}/src/gmock -I${with_gmock}/gtest -I${with_gmock}/gtest/include \
>      -I${with_gmock}/gtest/src"
>  
>  elif test "x$enable_bundled" != "xyes"; then
> </diff>
> 
> The same for the libgtest-dev imports. That could be solved, however
> 
> 3) the vendored package 3rdparty/nvml-352.79.tar.gz contains solely nvidia/gdk/nvml.h, but that
> appears not be DFSG-free.
> 
> 4) libelfio and picojson are both RFP (#839382, #773325), these could be packaged by, but
> 
> 5) the upstream tarball ships own patches for several of the vendored 3rdparts tarballs, like
> for glog 0.3.3, http-parser 2.6.2 (needs to be updated in Debian, #795492), leveldb 1.4, libev 4.22,
> protobuf 2.6.1, zookeeper 3.4.8. Some libraries like libprocess are forked in own 3rdparty (belonging
> to Mesos) repositories on Github (like https://github.com/3rdparty/libprocess). I haven't checked
> it closer so far, but it could be that there are many things which aren't (supposed to being?) integrated
> into the other projects.
> 
> I haven't given up, but I'm not so sure if there could be solutions for all of the points above if
> not wanted to ship most of the convenience packages with a mile long deb/copyright and just putting the
> thing into non-free because of (yet) a single file.
> 
> DS

... towards 5), https://github.com/3rdparty/glog is a better example, libprocess isn't a fork.

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: