1:30 a.m.
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.
6:36 a.m.
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.
7:01 a.m.
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
7:31 a.m.
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
7:38 a.m.
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.
9:24 p.m.
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
5:17 a.m.
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.
11:39 p.m.
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
3:52 p.m.
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
4:34 a.m.
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.
11:43 a.m.
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/...
Cheers,
Tim
----- Original Message -----
From: "Mathieu Bridon" <bochecha(a)fedoraproject.org>
To: "Development discussions related to Fedora"
<devel(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Cheers,
Tim
9:19 p.m.
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/...
That seems off-topic for this discussion, you should send that upstream
instead.
--
Mathieu
9:06 a.m.
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
9:14 a.m.
+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.kofler(a)chello.at>
To: devel(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Cheers,
Tim
10:12 p.m.
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
12:47 p.m.
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
3:21 p.m.
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 | mjg59(a)srcf.ucam.org
5:46 a.m.
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
11:42 p.m.
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
8:47 p.m.
New subject: 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
9:13 p.m.
New subject: 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.
9:15 p.m.
New subject: 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
3805
days inactive
3820
days old
21 comments
10 participants
participants (10)
-
Gilles J. Seguin -
Kevin Kofler -
Mathieu Bridon -
Matthew Garrett -
Michael Schwendt -
Orcan Ogetbil -
Rahul Sundaram -
Ralf Corsepius -
Simo Sorce -
Tim St. Clair