crazy /usr/lib/event.h (was: Packaging changes for libev in Rawhide)
On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want OMG i do not know what to say here /usr/lib/event.h -1 should -1,000,000,000 :-) i need a list of peoples making such uninspired suggestions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: crazy /usr/lib/event.h (was: Packaging changes for libev in Rawhide)
Hi On Tue, Dec 3, 2013 at 9:47 PM, Gilles J. Seguin wrote: OMG i do not know what to say here /usr/lib/event.h -1 should -1,000,000,000 :-) i need a list of peoples making such uninspired suggestions Even with a smiley, you haven't really added anything useful to the discussion. -1 or -1 million makes no difference whatsoever. The maintainer making the change has listed out his rationale. If you want to present yours, feel free to do so (without breaking the thread unnecessarily). Anything else is just noise. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: crazy /usr/lib/event.h (was: Packaging changes for libev in Rawhide)
On Tue, 2013-12-03 at 22:13 -0500, Rahul Sundaram wrote: Hi On Tue, Dec 3, 2013 at 9:47 PM, Gilles J. Seguin wrote: OMG i do not know what to say here /usr/lib/event.h -1 should -1,000,000,000 :-) i need a list of peoples making such uninspired suggestions Even with a smiley, you haven't really added anything useful to the discussion. -1 or -1 million makes no difference whatsoever. The maintainer making the change has listed out his rationale. If you want to present yours, feel free to do so (without breaking the thread unnecessarily). Anything else is just noise. In addition, I feel it's worth mentioning that nobody in this thread ever suggested that /usr/lib/event.h would be a good idea... or even an idea at all. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Sat, 23 Nov 2013 16:52:38 -0500, Orcan Ogetbil wrote: Can we have an event.h file that conditionally (or maybe even unconditionally) #includes the appropriate header file from either package? Both packages can then use the same event.h file without conflicts. It would also boil down to contacting all API consumers and requesting them to support that condition in their code. And if they did that, they could add configure checks instead, to detect event.h in alternative locations. Such as a subdirectory. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
Hi Michael, On Wed, 2013-11-20 at 12:17 +0100, Michael Schwendt wrote: On Wed, 20 Nov 2013 11:24:34 +0800, Mathieu Bridon wrote: I'm really just trying to fix all this mess here, so what do you think would be the better solution? To follow: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries In the case of the FPC not granting a bundling exception, perhaps they would permit building libev and perl-EV from the same src.rpm. The rationale for that would be how upstream handles the sources in CVS. I just opened FPC#369 asking for what the FPC think would be the proper solution: https://fedorahosted.org/fpc/ticket/369 Thanks for your feedback, hopefully we can get this fixed soon in Rawhide. :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
Hi, On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. I have just done that: http://koji.fedoraproject.org/koji/buildinfo?buildID=480826 Repeating below the information I had gathered to help maintainers of libev-using packages adapt their own packages. I'd be happy to help fix those packages if needed, I just can't do it myself (except for weighttp) as I'm neither a provenpackager nor a co-maintainer. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src [... snip ...] awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt - The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz -- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger - Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Mon, 2013-11-25 at 10:27 -0500, Nathaniel McCallum wrote: - Original Message - That's why I said I wouldn't make libev-devel conflict with libevent-devel. I said I would put the event.h header from libev into a libev-libevent-devel subpacke, and only this one would conflict with libevent-devel. I presume libverto uses ev.h from libev and event.h from libevent, right? In that case, it would still do that just fine even after I make the changes. I believe that should work. I'm happy to fix the .pc upstream requirement of libverto. This proposal seems sensible to me. Thanks Nathaniel. As I mentioned elsewhere, I have just done this in Rawhide. Basically, the upstream changes for libverto should be trivial: - libevent installs its event.h header in /usr/include, so you can link to that directly - libev installs its ev.h and ev++.h in /usr/include as well, so you can link directly to that. And that's pretty much it, there shouldn't be anything for you to do, except stop requiring the libev pkgconfig file (which I dropped in Rawhide). With this change, libverto should then build on all distributions, as we were (afaik) the only ones shipping a pkgconfig file for libev. Let me know if I can help. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Sat, 2013-11-23 at 13:47 -0500, Simo Sorce wrote: On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. Libverto builds against both libevent and libev being a event loop abstraction library, if you make libev and libevent conflict libeverto cannot be built anymore. That's why I said I wouldn't make libev-devel conflict with libevent-devel. I said I would put the event.h header from libev into a libev-libevent-devel subpacke, and only this one would conflict with libevent-devel. I presume libverto uses ev.h from libev and event.h from libevent, right? In that case, it would still do that just fine even after I make the changes. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. Libverto builds against both libevent and libev being a event loop abstraction library, if you make libev and libevent conflict libeverto cannot be built anymore. It makes not sense to make libev and libevent conflict, even if just in development headers. If upstream can;t see it then the distribution has to deal with it, which is what has been done with the changes you noted. Big -1 to revert those changes and breaking libverto in the process for no good reason whatsoever. CCed Nathaniel which is libverto's author. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Sat, Nov 23, 2013 at 01:47:49PM -0500, Simo Sorce wrote: On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. Libverto builds against both libevent and libev being a event loop abstraction library, if you make libev and libevent conflict libeverto cannot be built anymore. But it requires patches to libev that aren't upstream in order to build? One alternative would be to package the libev headers twice, one in the upstream location and once in the Fedora-specific location. The latter package could then include the pkgconfig file. This is still a bad solution. If libverto needs to link against both then libverto upstream should really work with libev and libevent upstream to find a solution that'll work for all distributions, rather than being limited to Fedora hacks. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, Nov 19, 2013 at 7:36 AM, Michael Schwendt wrote: On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) Seems plausible. Personally, I don't mind explicitly conflicting -devel packages, especially not if they are unlikely to be present in the same buildroot (and libev's event.h is a libevent compatibility header). Can we have an event.h file that conditionally (or maybe even unconditionally) #includes the appropriate header file from either package? Both packages can then use the same event.h file without conflicts. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
Mathieu Bridon wrote: * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) -1 Conflicts are evil, and this pointless conflict is very easily avoided by moving the header to a subdirectory as the package now does. (I actually think that BOTH libev and libevent should use a subdirectory for their headers. event.h is a very generic header name that doesn't belong in /usr/include at all.) Upstream needs to comprehend that they cannot just spam their headers directly into /usr/include; if they don't, we have no other choice than moving them without their consent. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
+1 to everything kevin just said. Just because other folks are employing bad practices, doesn't mean we should. If that means dependent packages need to add an extra -I location, that is a far better solution then polluting causing potential conflicts. Cheers, Tim - Original Message - From: Kevin Kofler kevin.kof...@chello.at To: devel@lists.fedoraproject.org Sent: Friday, November 22, 2013 9:06:07 AM Subject: Re: Packaging changes for libev in Rawhide Mathieu Bridon wrote: * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) -1 Conflicts are evil, and this pointless conflict is very easily avoided by moving the header to a subdirectory as the package now does. +1 (I actually think that BOTH libev and libevent should use a subdirectory for their headers. event.h is a very generic header name that doesn't belong in /usr/include at all.) +1 Upstream needs to comprehend that they cannot just spam their headers directly into /usr/include; if they don't, we have no other choice than moving them without their consent. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Fri, 2013-11-22 at 16:06 +0100, Kevin Kofler wrote: Mathieu Bridon wrote: * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) -1 Conflicts are evil, and this pointless conflict is very easily avoided by moving the header to a subdirectory as the package now does. (I actually think that BOTH libev and libevent should use a subdirectory for their headers. event.h is a very generic header name that doesn't belong in /usr/include at all.) Upstream needs to comprehend that they cannot just spam their headers directly into /usr/include; if they don't, we have no other choice than moving them without their consent. As said before, I disagree, and I want to get our package back in line with upstream and other distros. That being said, there is another possibility: if you feel so strongly that our current packaging of libev is the way it should be and it shouldn't change, then please take the package, so I'm not at the receiving end of users' requests and confusion. I argued the point with upstream, they refuse it, I don't feel like arguing more about it. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Wed, 20 Nov 2013 11:24:34 +0800, Mathieu Bridon wrote:
The current packaging approach is circumventing the packaging policies:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
perl-EV does not use the system libev. No real unbundling has been
achieved by replacing the bundled source with another copy at build-time.
A bug-fix (or security-fix) of libev would not affect perl-EV without
rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
dependency, but only:
BuildRequires: libev-source = %{version}
As a result, it is not ensured that a rebuild picks up the latest patched
libev-source. Even a buildroot override would be needed.
I know all that. :)
That makes it more difficult to answer.
In the original review request, it was mentioned to request an exemption
from FESCo: https://bugzilla.redhat.com/448613
In the ticket, you mention:
|
| [...] the bundled ones have always been identical to the system
| ones we use to build our libev package), but in that the built
| binaries are ABI-incompatible.
The ticket has been closed over a year later to restart with another review:
https://bugzilla.redhat.com/678221
In that ticket, the missing unbundling has not been commented on by the
reviewer. There is no explicit acknowledgement either. You explain:
|
| There's a bundled copy of libev in the source RPM.
|
| At build-time, I remove this folder and use instead the sources coming
| from the Fedora libev-source package, to avoid building against the
| bundled copy (this is what is done by other packages such as tigervnc
| that uses the sources from Xorg).
Effectively, and repeating that cannot be avoided, you restore the bundled
sources, an no unbundling is done. More precisely, you replace the
bundled sources with a copy that may be different (especially for the case
that libev is at a different version than what is bundled with perl-EV).
Nobody care foresee how long the sources will be identical. Currently,
upstream perl-EV in CVS does not include a bundled libev, but refers to the
separate libev project in CVS. Anyone, who checks out perl-EV from CVS
will need to check out libev, since the bundling is only done for the
tarball release - so far.
Unbundling was a pre-requisite of the review request, though, and the
reviewer found the current solution more acceptable than keeping the
bundled libev in perl-EV.
I'm really just trying to fix all this mess here, so what do you think
would be the better solution?
To follow:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
In the case of the FPC not granting a bundling exception, perhaps they
would permit building libev and perl-EV from the same src.rpm. The rationale
for that would be how upstream handles the sources in CVS.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Developers, who base their work on Fedora's *-devel packages, will publish something that's incompatible with pristine upstream releases. Unless they make their software detect the different install locations (or renamed libs even). 2. we ship a pkgconfig file, which upstream does not want A .pc file only adds value, if every API consumer uses pkg-config. Where pkg-config is not used, locating moved headers becomes troublesome, and lazy developers would simply hardcode search paths in Makefiles, or worse, in #include-statements. I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. To be fair, a single bug report doesn't have much weight. It's easy enough to list the package contents and notice where the headers are stored. The differences between multiple distributions (as well as upstream) are not so good, however. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. Agreed. Though, this is more of a problem for the API consumers, who ought to support not just Fedora's libev packages but also pristine upstream libev. Afterall, their software would only build for Fedora. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) Seems plausible. Personally, I don't mind explicitly conflicting -devel packages, especially not if they are unlikely to be present in the same buildroot (and libev's event.h is a libevent compatibility header). But in general, conflicts bear a risk and may lead to future problems, and I would have opened this thread on packaging@ list instead. * Drop our pkgconfig file. Upstream really doesn't like pkgconfig. Does anybody have any comment, or objection? This one is weird: https://bugzilla.redhat.com/672153 In order to make the perl-EV package not use a bundled libev source, you build a libev-source subpackage that perl-EV adds as BuildRequires. In other words, perl-EV now still bundles libev, but only indirectly. An update of libev does not affect perl-EV until perl-EV is rebuilt. libev has been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt. Such a dependency ought to be tracked in a special way, preferably with official blessing from the FPC. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 13:36 +0100, Michael Schwendt wrote: On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Developers, who base their work on Fedora's *-devel packages, will publish something that's incompatible with pristine upstream releases. Unless they make their software detect the different install locations (or renamed libs even). That's in fact what is happening, which is why I'd like to get the Fedora package inline with upstream and other distros. 2. we ship a pkgconfig file, which upstream does not want A .pc file only adds value, if every API consumer uses pkg-config. Where pkg-config is not used, locating moved headers becomes troublesome, and lazy developers would simply hardcode search paths in Makefiles, or worse, in #include-statements. I agree, but again, upstream refused it several times (Michal, the original libev maintainer offered it, I did, the awesome developers did too,...) At this point, I really just want to have the Fedora package inline with upstream, so that consumers of the library use it the same way everywhere. Personally, I don't mind explicitly conflicting -devel packages, especially not if they are unlikely to be present in the same buildroot (and libev's event.h is a libevent compatibility header). So, libev's ev.h and libevent's event.h might very well be installed on the same system, in the case of a developer working on two different applications, or on something like libverto (a wrapper for different event loops). But libev's event.h and libevent's event.h should not. But in general, conflicts bear a risk and may lead to future problems, and I would have opened this thread on packaging@ list instead. Oh? Should we move there now? I thought devel@ was better, as it needed to reach the maintainers of the packages which build against libev. Does anybody have any comment, or objection? This one is weird: https://bugzilla.redhat.com/672153 In order to make the perl-EV package not use a bundled libev source, you build a libev-source subpackage that perl-EV adds as BuildRequires. In other words, perl-EV now still bundles libev, but only indirectly. An update of libev does not affect perl-EV until perl-EV is rebuilt. libev has been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt. Right, it's certainly unorthodox. The problem is that libev is actually intended to be bundled by upstream, and perl-EV is made by the same people. As a result, they **really** don't want to unbundle libev from perl-EV. The approach I followed was a compromise, it's definitely not the most desirable outcome. Such a dependency ought to be tracked in a special way, preferably with official blessing from the FPC. I didn't pass it through FPC because there are a few precedents. The one I inspired myself from is xorg-x11-server-source. I assumed that given there were already quite a few of these, it was an accepted practice. Did I assume wrong? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On 11/19/2013 02:01 PM, Mathieu Bridon wrote: On Tue, 2013-11-19 at 13:36 +0100, Michael Schwendt wrote: On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Upstream needs to comprehend, they do not have any control over installation locations. Users/system integrators/installers have the freedom to choose installations locations at their choice, at free will. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 19 Nov 2013 21:01:06 +0800, Mathieu Bridon wrote:
This one is weird:
https://bugzilla.redhat.com/672153
In order to make the perl-EV package not use a bundled libev source,
you build a libev-source subpackage that perl-EV adds as BuildRequires.
In other words, perl-EV now still bundles libev, but only indirectly. An
update of libev does not affect perl-EV until perl-EV is rebuilt. libev has
been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt.
Right, it's certainly unorthodox.
The problem is that libev is actually intended to be bundled by
upstream, and perl-EV is made by the same people.
It's similar with libeio (retired) and Perl IO::AIO by the same author.
The Perl module contains a renamed and private DSO lib built from a
bundled copy of the library sources. Even if the Perl module could be
patched to use the system-wide DSO lib instead, there are no guarantees
about API/ABI stability. Even if the system lib has been compatible for a
long time, it may break in future releases, and e.g. the module may include
a modified bundled lib source eventually.
As a result, they **really** don't want to unbundle libev from perl-EV.
The approach I followed was a compromise, it's definitely not the most
desirable outcome.
Such a dependency ought to be tracked in a special way, preferably with
official blessing from the FPC.
I didn't pass it through FPC because there are a few precedents. The one
I inspired myself from is xorg-x11-server-source.
I assumed that given there were already quite a few of these, it was an
accepted practice.
Did I assume wrong?
I think so.
The current packaging approach is circumventing the packaging policies:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
perl-EV does not use the system libev. No real unbundling has been
achieved by replacing the bundled source with another copy at build-time.
A bug-fix (or security-fix) of libev would not affect perl-EV without
rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
dependency, but only:
BuildRequires: libev-source = %{version}
As a result, it is not ensured that a rebuild picks up the latest patched
libev-source. Even a buildroot override would be needed.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch Cheers, Tim - Original Message - From: Mathieu Bridon boche...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 19, 2013 1:30:46 AM Subject: Packaging changes for libev in Rawhide Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt - The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz -- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger - Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 12:43 -0500, Tim St Clair wrote: Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. I actually agree with that. Upstream libev doesn't, though. And with our current package in Fedora, we are creating a situation where developers of software using libev have to juggle weirdly to support Fedora because it's different from upstream libev and other distros. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch That seems off-topic for this discussion, you should send that upstream instead. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 14:38 +0100, Michael Schwendt wrote:
On Tue, 19 Nov 2013 21:01:06 +0800, Mathieu Bridon wrote:
This one is weird:
https://bugzilla.redhat.com/672153
In order to make the perl-EV package not use a bundled libev source,
you build a libev-source subpackage that perl-EV adds as BuildRequires.
In other words, perl-EV now still bundles libev, but only indirectly. An
update of libev does not affect perl-EV until perl-EV is rebuilt. libev
has
been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been
rebuilt.
Right, it's certainly unorthodox.
The problem is that libev is actually intended to be bundled by
upstream, and perl-EV is made by the same people.
It's similar with libeio (retired) and Perl IO::AIO by the same author.
The Perl module contains a renamed and private DSO lib built from a
bundled copy of the library sources. Even if the Perl module could be
patched to use the system-wide DSO lib instead, there are no guarantees
about API/ABI stability. Even if the system lib has been compatible for a
long time, it may break in future releases, and e.g. the module may include
a modified bundled lib source eventually.
As a result, they **really** don't want to unbundle libev from perl-EV.
The approach I followed was a compromise, it's definitely not the most
desirable outcome.
Such a dependency ought to be tracked in a special way, preferably with
official blessing from the FPC.
I didn't pass it through FPC because there are a few precedents. The one
I inspired myself from is xorg-x11-server-source.
I assumed that given there were already quite a few of these, it was an
accepted practice.
Did I assume wrong?
I think so.
The current packaging approach is circumventing the packaging policies:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
perl-EV does not use the system libev. No real unbundling has been
achieved by replacing the bundled source with another copy at build-time.
A bug-fix (or security-fix) of libev would not affect perl-EV without
rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
dependency, but only:
BuildRequires: libev-source = %{version}
As a result, it is not ensured that a rebuild picks up the latest patched
libev-source. Even a buildroot override would be needed.
I know all that. :)
Unbundling was a pre-requisite of the review request, though, and the
reviewer found the current solution more acceptable than keeping the
bundled libev in perl-EV.
I'm really just trying to fix all this mess here, so what do you think
would be the better solution?
Thanks,
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaging changes for libev in Rawhide
Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt - The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz -- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger - Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
