eio from eio provides libeio.so.1()(64bit) libeio from libeio provides libeio.so.1()(64bit) required by: eio-devel-1.7.8-1.fc20.x86_64 required by: emotion-1.7.8-8.fc20.x86_64 required by: libeio-devel-4.18-3.fc20.x86_64 The conflict had been mentioned in the review request in bug 891244 comment 1 but later on nothing has been done to avoid/resolve the conflict. The original attempt (moving lib and pkgconfig files) has been invalid.
In this case, the colliding SONAME Provides are not even only a theoretical problem. The resolver did not choose "eio": # yum install emotion ... --> Processing Dependency: libeio.so.1()(64bit) for package: emotion-1.7.8-8.fc20.x86_64 ... ---> Package libeio.x86_64 0:4.18-3.fc20 will be installed ... Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: emotion x86_64 1.7.8-8.fc20 fedora 107 k Installing for dependencies: ecore x86_64 1.7.8-2.fc20 fedora 357 k edje x86_64 1.7.8-3.fc20 fedora 329 k eet x86_64 1.7.8-2.fc20 fedora 76 k eeze x86_64 1.7.8-2.fc20 fedora 18 k embryo x86_64 1.7.8-3.fc20 fedora 87 k evas x86_64 1.7.8-1.fc20 fedora 1.3 M libeina x86_64 1.7.8-1.fc20 fedora 150 k libeio x86_64 4.18-3.fc20 fedora 22 k tslib x86_64 1.0-7.fc20 fedora 66 k
Yeah. This sucks.
Hi! I see you requested ACLs on libeio, but it is unclear to me what exactly you plan to do to it to resolve this issue. BTW, it's generally considered polite to contact the existing maintainers of a package and announce your intentions with regards to it when you wish to join them as a comaintainer. I usually don't bother responding when the only message I get is from a robot.
(In reply to T.C. Hollingsworth from comment #3) > Hi! I see you requested ACLs on libeio, but it is unclear to me what > exactly you plan to do to it to resolve this issue. > > BTW, it's generally considered polite to contact the existing maintainers of > a package and announce your intentions with regards to it when you wish to > join them as a comaintainer. I usually don't bother responding when the > only message I get is from a robot. Hi TC. Plans are to retire/block this package and update/use libeio instead. I hope that clears it up?
Never mind. Let me try the patch mentioned in comment 1.. TC can you confirm that libeio is used for a different purpose?
The only reason why I've mentioned bug 891244 comment 1 is that during the review the conflict has been discovered but has not been replied to, and it has been ignored completely later. Moving the library to some other location won't help, since the SONAME and the automatic Provides/Requires would still conflict. And putting back the lib into run-time linker's search path with a ld.so.conf script would not be a solution either, since that would only be an option for _compatible_ libs in alternative packages where you only need to work around the file conflict, and where _either one_ would satisfy a run-time dependency on the lib name. What would need to happen? Try to get either library renamed. Talk to the upstreams. libeio is: http://software.schmorp.de/pkg/libeio.html At Fedora, nothing uses it yet. Are there public projects that use it already?
(In reply to Michael Schwendt from comment #6) > The only reason why I've mentioned bug 891244 comment 1 is that during the > review the conflict has been discovered but has not been replied to, and it > has been ignored completely later. > > Moving the library to some other location won't help, since the SONAME and > the automatic Provides/Requires would still conflict. And putting back the > lib into run-time linker's search path with a ld.so.conf script would not be > a solution either, since that would only be an option for _compatible_ libs > in alternative packages where you only need to work around the file > conflict, and where _either one_ would satisfy a run-time dependency on the > lib name. > > What would need to happen? > > Try to get either library renamed. Talk to the upstreams. > > libeio is: http://software.schmorp.de/pkg/libeio.html > At Fedora, nothing uses it yet. Are there public projects that use it > already? Thanks Michael for being so helpful. E upstream hasn't been very responsive unfortunately. I would like to see TC's reply to see if these 2 are related. We can just use the patch previously mentioned and/or wait for TC's reply.
> if these 2 are related. How do you mean that? They implement similar things but with an entirely different API, a different implementation and a different feature set. > We can just use the patch previously mentioned No, we can't. See comment 6, please.
(In reply to Dan Mashal from comment #5) > Never mind. Let me try the patch mentioned in comment 1.. > > TC can you confirm that libeio is used for a different purpose? Yeah, it's a completely different codebase. That's why I was confused at first. :-) (In reply to Michael Schwendt from comment #6) > What would need to happen? > > Try to get either library renamed. Talk to the upstreams. > > libeio is: http://software.schmorp.de/pkg/libeio.html > At Fedora, nothing uses it yet. Are there public projects that use it > already? Actually, nothing uses it *anymore*. ;-) Node.js used to bundle it, and it was packaged during the effort to unbundle all the libraries from node. But upstream "fixed" their bundling problem by not using this library anymore, so it's no longer needed. I've kept it alive because some of the old packages I maintained in a third-party repository back before node got into Fedora depended on it, but they haven't been built since F17 so it's high time I just killed it. I have already sent the requisite missive to devel.o. If nobody else needs it, retiring it should solve your problem nicely.
Works for me.
Meanwhile, I've received a reply from both upstreams. One eio maintainer has responded in less than a quarter of an hour. That's very fast. So, at least they are informed about the issue.
D'oh! Somebody had pointed out the conflict already many months before when Fedora did not include package "eio" yet and the E17 release mentioned problems, too: > http://edmann.com/Open-Source/2012/12/21/Enlightenment-17-Final-Release > > If you have issues with the yum install let me know. I know there was > one person that said eio and libeio were causing issues. If you have > issues please post in the comments and let me know about your setup. > I am trying to figure out why i cannot replicate this issue. In the comments: > libeio conflicts with eio > > March 27th 2013 at 09:03 am > > If you already have libeio package, you cannot install your eio > package since it provides a file which is already in libeio from > fedora: file /usr/lib64/libeio.so.1 from install of > libeio-4.18-1.fc18.x86_64 conflicts with file from package > eio-1.7.5-0.enl.fc18.x86_6 [...] Also interesting, in Debian there is EIO as libeio1 and libeio-dev (EIO headers and static libraries). Plans from 2011 about unbundling libeio: http://debian.2.n7.nabble.com/Packaging-libeio-used-by-nodejs-and-libio-aio-perl-separately-td1849744.html
(In reply to Michael Schwendt from comment #11) > Meanwhile, I've received a reply from both upstreams. One eio maintainer has > responded in less than a quarter of an hour. That's very fast. > > So, at least they are informed about the issue. But no plans to do anything? :-( (In reply to Michael Schwendt from comment #12) > Also interesting, in Debian there is EIO as libeio1 and libeio-dev (EIO > headers and static libraries). > > Plans from 2011 about unbundling libeio: > http://debian.2.n7.nabble.com/Packaging-libeio-used-by-nodejs-and-libio-aio- > perl-separately-td1849744.html Those plans never seem to have come to fruition. Their "libeio1" is the Enlightenment codebase and there's no evidence of the schmorp.de in their package repository that I can find. Anyway, since the perl-IO-AIO doesn't seem to care about that package much anymore and unbundling libeio from looks like a lot of effort nobody is interested in (see my mail to devel) it looks like this still will get fixed with the death of libeio.
(In reply to T.C. Hollingsworth from comment #13) > (In reply to Michael Schwendt from comment #11) > > Meanwhile, I've received a reply from both upstreams. One eio maintainer has > > responded in less than a quarter of an hour. That's very fast. > > > > So, at least they are informed about the issue. > > But no plans to do anything? :-( > > (In reply to Michael Schwendt from comment #12) > > Also interesting, in Debian there is EIO as libeio1 and libeio-dev (EIO > > headers and static libraries). > > > > Plans from 2011 about unbundling libeio: > > http://debian.2.n7.nabble.com/Packaging-libeio-used-by-nodejs-and-libio-aio- > > perl-separately-td1849744.html > > Those plans never seem to have come to fruition. Their "libeio1" is the > Enlightenment codebase and there's no evidence of the schmorp.de in their > package repository that I can find. > > Anyway, since the perl-IO-AIO doesn't seem to care about that package much > anymore and unbundling libeio from looks like a lot of effort nobody is > interested in (see my mail to devel) it looks like this still will get fixed > with the death of libeio. Thanks
libeio is now retired. Release Engineering will need to block libeio in koji, [1] and then these conflicts should vanish in the next compose following that. [1] https://fedorahosted.org/rel-eng/ticket/5778
> Removed package: libeio-4.18-3.fc20 With the last published build being libeio-4.18-2.fc19, "eio" will still need to do Obsoletes: libeio < 4.18-3 to replace/hide the conflicting "libeio" packages in the repos.
(In reply to Michael Schwendt from comment #16) > > Removed package: libeio-4.18-3.fc20 > > With the last published build being libeio-4.18-2.fc19, "eio" will still > need to do > > Obsoletes: libeio < 4.18-3 > > to replace/hide the conflicting "libeio" packages in the repos. Doing it now. Thanks.
Oh, and the same in eio-devel for libeio-devel, of course.
eio-1.7.8-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/eio-1.7.8-2.fc19
eio-1.7.8-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/eio-1.7.8-2.fc20
Package eio-1.7.8-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing eio-1.7.8-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17513/eio-1.7.8-2.fc20 then log in and leave karma (feedback).
eio-1.7.8-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
eio-1.7.8-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.