Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Using external libevent
From: Orion Poplawski (orion_at_[hidden])
Date: 2013-04-17 13:40:07

> On Apr 16, 2013, at 9:22 PM, Orion Poplawski <orion_at_[hidden]> wrote:
>> I'm starting to take a look at updating openmpi in Fedora to 1.7. It
looks like openmpi is now bundling a copy of libevent, which is generally
forbidden in Fedora.

> FWIW, we've always bundled libevent -- ever since 1.0. It was made a little
more obvious in 1.7 because we shifted some things around in the build system,
but it's always been there.

>> Is there any work being done on allowing one to compile against an
external libevent library?
> We have not done this because OMPI is fairly tied to the specific version
of libevent that is bundled.

> Given that OMPI has *always* bundled libevent, how terrible would it be to
just let that continue?

Well, it goes against Fedora policy and now that it has been detected,
something has to be done about it. We can apply for an exception, in which
case we need to answer the following questions from

      Has the library behaviour been modified? If so, how has it been
modified? If the library has been modified in ways that change the API or
behaviour then there may be a case for copying. Note that fixing bugs is not
grounds to copy. If the library has not been modified (ie: it can be used
verbatim in the distro) there's little chance of an exception.
         Why haven't the changes been pushed to the upstream library? If no
attempt has been made to push the changes upstream, we shouldn't be supporting
people forking out of laziness.
         Have the changes been proposed to the Fedora package maintainer for
the library? In some cases it may make sense for our package to take the
changes despite upstream not taking them (for instance, if upstream for the
library is dead).
     Could we make the forked version the canonical version within Fedora? For
instance, if upstream for the library is dead, is the package we're working on
that bundles willing to make their fork a library that others can link against?
     Are the changes useful to consumers other than the bundling application?
If so why aren't we proposing that the library be released as a fork of the
upstream library?
     Is upstream keeping the base library updated or are they continuously one
or more versions behind the latest upstream release?
     What is the attitude of upstream towards bundling? (Are they eager to
remove the bundled version? are they engaged with the upstream for the
library? Do they have a history of bundling? Are they argumentative?)
     Overview of the security ramifications of bundling
     Does the maintainer of the Fedora package of the library being bundled
have any comments about this?
     Is there a plan for unbundling the library at a later time? Include
things like what features would need to be added to the upstream library, a
timeline for when those features would be merged, how we're helping to meet
those goals, etc.

So, would you be willing to provide more of the rationale as to why libevent
is bundled?


Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion_at_[hidden]
Boulder, CO 80301