[
https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy St. Clair updated MESOS-898:
------------------------------------
Summary: Transform and audit mesos build process (was: Transform build to
cmake to rid repository of tarballs.)
> Transform and audit mesos build process
> ---------------------------------------
>
> Key: MESOS-898
> URL: https://issues.apache.org/jira/browse/MESOS-898
> Project: Mesos
> Issue Type: Improvement
> Components: build
> Reporter: Timothy St. Clair
> Labels: build
>
> This is a rather substantial undertaking, so I would want upstream
> debate+buy-in prior to full commitment. The basic premise is: upstream
> rebundles several of its dependencies in part to tightly control its stack.
> This is not out of the norm, but in order to be picked up by distribution
> channels it needs to built against system dependencies, and rebundling is
> strictly forbidden. Given that the mesos primary target platform are
> data-center distributions such as RHEL/CENTOS/SL it makes sense to still have
> bundling support for those who do not have dependencies in their channels
> "yet". This is where cmake can be win with it's uber macros
> (http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject).
> I do not know of any equivalent in the autotools world, other then to brew
> your own encabulator. I've done this type of work in the past, and
> completely transformed condor and would leverage a lot of the work that was
> done there.
> I currently have a tracking branch where I've started this work, but before I
> go off into the woods, it makes sense to have a debate in public.
> The benefits are:
> 1. Enable downstream channels to easily distro without carrying a large patch
> set.
> 2. Still support existing "non-proper" distribution methods.
> Costs:
> 1. Time
> 2. Sanity
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
