[
https://issues.apache.org/jira/browse/MESOS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180280#comment-14180280
]
Till Toenshoff commented on MESOS-1940:
---------------------------------------
Let me try to look at this from the user's perspective who needs to work with
the results of this discussion.
The trivial use-case up front: supplying a full module library path via
--modules certainly is always possible..
The less trivial case would be allowing the user to supply library names
without supplying an absolute path. Do we want to cover this case? If so, then
there seem to be at least two options:
A. Use the configuration-phase prefixed lib-folder (e.g. /usr/local/lib) and
rely on ldconfig to initialize that location.
B. Use a more specific, mesos-module location (e.g. /usr/local/lib/mesos) and
allow mesos to use that location by default (again due to configuration-phase
prefixed location) which could then be overridden by a --modules_path flag.
Using an ldconfig indexed path certainly makes things rather quick and easy on
the integration side. It may however be considered a bit untidy as these
modules are very much mesos specific, hence they should not "clutter" a
regular, all-purpose shared object folder. cyrus-sasl2 does use option B with
its mechanism plugins.
> Add Mesos-graced/hosted libraries to installation path
> ------------------------------------------------------
>
> Key: MESOS-1940
> URL: https://issues.apache.org/jira/browse/MESOS-1940
> Project: Mesos
> Issue Type: Task
> Reporter: Niklas Quarfot Nielsen
>
> When more modules are going to show up within the Mesos source base (and even
> with sample/test modules) it would be convenient to have them be installed
> alongside the regular Mesos binaries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
