#403 Resolve conflict between libeio and eio (enlightenment library)
Closed: Fixed None Opened 10 years ago by jkaluza.

This is a request to grant a bundling exception for rubygem-passenger (aka. mod_passenger, Passenger), which bundles libeio library.

I've been working with Passenger upstream to make the Fedora Passenger package more consistent with what upstream distributes. This leaded to decision to rename "rubygem-passenger" to "passenger" (accepted by the current "rubygem-passenger" maintainer/co-maintainers).

Following the rename process, I've created review request [1]. In this review request, reviewer found out that the Passenger bundles libeio library.

From the Passenger point of view, it should not be a problem to use the system version of libeio, but the situation is more complicated.

Libeio was in Fedora in the past, but it has been retired last year [2]. I would have no problem with maintaining the libeio myself, but it conflicts [3] with "eio" package provided by Englightenmnent. This is completely different project, but shares the same library name.

So the current situation is that we have rubygem-passenger bundling libeio and a review which is blocked by this bundling. We can't easily package libeio without adding conflicts.

Possible solutions to this situation could be:

  1. Rename one library

This is not acceptable by the original libeio upstream and I presume Enlightenment developers would think so too about their libeio, although I haven't asked any Enlightenment developer yet.

  1. Rename libeio just for fedora

I'm not sure that's sane decision, but it would fix this issue and if FPC is not against, why not... The problem here is that applications using this renamed library would have to be patched probably during the packaging...

  1. Package libeio again and keep the conflict

This would mean we can't have enlightenment and libeio installed together.

  1. Allow Passenger to bundle libeio

This reflects current situation. I currently don't have better idea how to fix this problem. I think other solutions I see are less sane than this one.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1074515
[2] http://osdir.com/ml/fedora-development/2013-09/msg00648.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1003692


Bundling would be inappropriate in this situation.

http://fedoraproject.org/wiki/Packaging:Conflicts is what you want.

Try talking to the enlightement and eio upstreams to see if they'd be willing to rename. If not, fedora will have to rename one of the libraries. From the bug report between mschwendt and patches I lean a bit towards eio being renamed in fedora but I don't have all the information. Maybe there's a case for enlightenment's library to be renamed instead.

And yes, this sucks. Upstreams using conflicting names and not being willing to rename when the problem is pointed out is a horrible situation everytime it occurs.

I will try contacting enlightenment upstream too. After the discussion with libeio upstream on IRC today, I'm quite sure they won't rename the library.

They think it's enlightenment's Eio which should be renamed, because it's mostly "internal" library for Enlightenment and their libeio is here for longer time and used by more external projects which would have to be rewritten. Of course that's just libeio's upstream point of view and does not have to be objective, but that's what they think.

<nod> Those would be good reasons for us to decide that Enlightenment's libeio is what should be renamed in fedora (if it comes to that).

If Enlightenment's libeio is truly an internal library, it's also possible to make it an internal library via rpath: https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries (Not instructions, just a link to show that that use of rpath is allowed).

I've asked on enlightenment-devel and it looks like they don't see a solution for that on their side. Their Eio library is part of public and supported API and can be used by external projects.

Full response: http://sourceforge.net/p/enlightenment/mailman/message/32090859/

I personally think that if bundling is not possible, we should rename libeio (the one needed by Passenger), because it's not in distribution yet and simply requires less applications to be patched (just Passenger).

The question is what name should be used? Did that happen in the past and is here some consensus on that (like adding some common suffix)? Should the headers rename too? Eio provides Eio.h while libeio provides eio.h.

Ok, one more information from Passenger upstream about their usage of libeio:

As for libeio: upstream doesn't have any releases, they expect you to
pull the source code from CVS. Phusion Passenger has only been tested
against the revision from 2012-11-02. libeio provides no compatibility
guarantees so there is no telling what would happen if it is compiled
against any other version of libeio.

That could fit into possible bundle exception, right?

The "full response" in comment 6 refers to Fedora not "another distribution" ( http://pkgs.fedoraproject.org/cgit/libeio.git/plain/dead.package ) since we've been in contact with both the libeio and Enlightenment upstreams at that time, too. libeio upstream's stance has been that it's the distributor's responsibility (and freedom) to resolve conflicts such as this one. Contact with Enlightment upstream has been brief only, but basically they responded: "too late to rename".

At last week's meeting we did not have quorum but we took a vote of present members:
Allow passenger to bundle libeio (+1:0, 0:0, -1:3).

My estimate is this is unlikely to pass. If you desire we can continue voting until we reach either +5 or -5. However, I think it's more profitable to look into renaming. The Packaging guidelines say that maintainers needing to rename should try to coordinate with other distros and calls out the distributions @ freedesktop.org mailing list as one place that could be done: http://lists.freedesktop.org/mailman/listinfo/distributions

CC'ing the eio maintainer in case he's needed.

I've written email to distributions mailing list: http://lists.freedesktop.org/archives/distributions/2014-March/000695.html

I'm quite skeptical about the response (but well, lets see).

In case of no interest from other distributions (libeio is not packaged in most of them), what should I do next? Rename libeio just in Fedora?

I don't want the Phusion Passenger review to stuck on this forever (given the fact that it bundles libeio for long time).

Crazy/silly idea: rename both. Ask both upstreams (and distributions list) for preference/input on naming, but make it clear that not renaming is not an option.

This is at least more fair, and doesn't play sides or favorites.

Re: no response: yeah, Choose a name to rename within Fedora. Choose something that other distributions would be okay to use as well. Then send an announcement to distributions list to let them know of the name we chose in Fedora.

Re: renaming both. Yeah, we can do that. Usually, though, if one maintainer is willing to rename the package they are in charge of in Fedora we don't require both to rename. It's a bit unfair to upstream but it makes for less conflict within the distribution. We usually only require both packages to rename inside of Fedora if both neither maintainer wants to rename (as in that case, requiring both to rename is the only fair option).

It's almost 14 days without any response. I've started thinking about better name for libeio library to use it in Fedora. I think I will use "libev-eio" if nobody is against. I will wait for the end of the week to give FPC some time to step in if needed and then I will write this decision to distributions mailing list and package "libeio" renamed as "libev-eio" probably.

If you have idea for better name, feel free to share.

I sent an email about my intention to use libev-eio in Fedora to distributions mailing list.

http://lists.freedesktop.org/archives/distributions/2014-April/000697.html

Just for your info, I've created review request for libeio with renamed libeio.so to libev-eio.so: https://bugzilla.redhat.com/show_bug.cgi?id=1097089

Login to comment on this ticket.

Metadata