Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] Using external libevent
From: Ralph Castain (rhc_at_[hidden])
Date: 2013-04-17 13:49:36

Wouldn't that be something best left to the Fedora folks to decide? They have been bundling OMPI with Fedora for a long time, and knew we were including libevent since the beginning.

You are welcome to remind them of it - might be best to see what they have to say before we jump.

On Apr 17, 2013, at 10:40 AM, Orion Poplawski <orion_at_[hidden]> wrote:

> > 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?
> Thanks!
> --
> 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
> _______________________________________________
> devel mailing list
> devel_at_[hidden]