Hi,
I'm packaging serf into Fedora.
Here is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=973904
However, the reviewer said that this package should follow how was packaged in oter distros.
Debian and OpenSUSE install headers to /usr/include/serf-1/*.h, but I just packaged them to /usr/include/*.h
Now I decide to install them to a new folder, should I keep updated with Debian or OpenSUSE, and install them to /usr/include/serf-1/, or to /usr/include/serf/?
Thanks.
Yours sincerely, Christopher Meng
Always playing in Fedora Project
On Sun, 16 Jun 2013 17:35:44 +0800, Christopher Meng wrote:
Hi,
I'm packaging serf into Fedora.
Here is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=973904
However, the reviewer said that this package should follow how was packaged in oter distros.
That's somewhat unusual.
While we've got naming guidelines, which sometimes make it plausible to use package names that are used by other dists already, spending time on examining other dists' packages on where they store header files is beyond the scope of packaging for Fedora.
So, where does upstream install those headers?
You use the default location so far, since you don't modify the configure script's --includedir parameter: http://cicku.me/libserf.spec
Debian and OpenSUSE install headers to /usr/include/serf-1/*.h, but I just packaged them to /usr/include/*.h
Now I decide to install them to a new folder, should I keep updated with Debian or OpenSUSE, and install them to /usr/include/serf-1/, or to /usr/include/serf/?
This depends on where dependencies expect these headers to be found. Do they evaluate the serf-1.pc pkgconfig --cflags to retrieve a custom search path for headers? Do external sources include the headers via standard search path, i.e.
#include <serf.h>
or
#include <serf-1/serf.h>
? Do they use a hardcoded /usr/include/serf-1 search path? What is the full story here?
%{_libdir}/pkgconfig/%{oname}*.pc
Hint: it can be very helpful to use _less_ wildcards for important files like this one. If the filename changes, the automated RPM pkgconfig deps would change and break dependencies without warning you. Better spell out the full name of this file, because that would make the build fail and serve as an early-warning-system. (a similar thing may apply to other important file types, e.g. libs)
BuildRequires: glibc-devel
It's part of the minimum build environment and doesn't need to be specified in the spec file.
%package devel Requires: %{name}%{?_isa} = %{version}-%{release} Requires: apr-util-devel Requires: apr-devel Requires: krb5-devel Requires: libgssapi-devel Requires: openssl-devel Requires: zlib-devel
Here you should append %{?_isa} just like for the base package Requires. But are all these really required?
$ grep #include serf* serf_bucket_types.h:#include <apr_mmap.h> serf_bucket_types.h:#include <apr_hash.h> serf_bucket_types.h:#include "serf.h" serf_bucket_util.h:#include "serf.h" serf.h:#include <apr.h> serf.h:#include <apr_errno.h> serf.h:#include <apr_allocator.h> serf.h:#include <apr_pools.h> serf.h:#include <apr_network_io.h> serf.h:#include <apr_time.h> serf.h:#include <apr_poll.h> serf.h:#include <apr_uri.h> serf.h:#include "serf_bucket_types.h"
Le 16/06/2013 12:28, Michael Schwendt a écrit :
On Sun, 16 Jun 2013 17:35:44 +0800, Christopher Meng wrote:
However, the reviewer said that this package should follow how was packaged in oter distros.
That's somewhat unusual.
I don't say that.
I mostly encourage to use a sub-folder of /usr/include instead of simply drop the headers in the main /usr/include dir
And in that case "serf-1" (used in other distro seems a good choice)
While we've got naming guidelines, which sometimes make it plausible to use package names that are used by other dists already, spending time on examining other dists' packages on where they store header files is beyond the scope of packaging for Fedora.
Yes.
But looking outside fedora is always interesting. We don't need to reinvent the wheel.
Lot of us use path from debian or other distro. Other distro also take patches from our repo.
This depends on where dependencies expect these headers to be found. Do they evaluate the serf-1.pc pkgconfig --cflags to retrieve a custom search path for headers? Do external sources include the headers via standard search path, i.e.
Definitively, pkg-config output is the right way.
I only know about pecl/http which use an awful solution
if test -f "$i/include/serf-0/serf.h"; then SERF_DIR=$i SERF_VER=0 elif test -f "$i/include/serf-1/serf.h"; then SERF_DIR=$i SERF_VER=1 fi
Here you should append %{?_isa} just like for the base package Requires. But are all these really required?
How could I have miss that.... :(
Remi.
On Sun, 16 Jun 2013 17:50:07 +0200, Remi Collet wrote:
I mostly encourage to use a sub-folder of /usr/include instead of simply drop the headers in the main /usr/include dir
That's a good recommendation when header filenames bear a risk of causing conflicts. It can also be beneficial when planning to package multiple parallel-installable versions of a library API. That doesn't mean we install all headers into versioned subdirs.
And libserf uses a "serf" prefix for its header names, so storing these headers in standard search path isn't too bad.
$ rpmls -p libserf-devel-1.2.1-2.fc19.x86_64.rpm|grep inc -rw-r--r-- /usr/include/serf.h -rw-r--r-- /usr/include/serf_bucket_types.h -rw-r--r-- /usr/include/serf_bucket_util.h
And in that case "serf-1" (used in other distro seems a good choice)
And may be troublesome for projects, which expect libserf headers to be found in standard search path. It would become necessary to patch them and e.g. make them use pkgconfig. On the contrary, the project developer who doesn't use pkgconfig might '#include <serf-1/serf.h>', and that wouldn't be compatible with the pristine upstream release defaults.
But looking outside fedora is always interesting.
Where to start? Where to stop?
Lot of us use path from debian or other distro. Other distro also take patches from our repo.
Upstream, upstream, upstream.
This depends on where dependencies expect these headers to be found. Do they evaluate the serf-1.pc pkgconfig --cflags to retrieve a custom search path for headers? Do external sources include the headers via standard search path, i.e.
Definitively, pkg-config output is the right way.
Please talk to upstream about this customised header location. Try getting upstream to use /usr/include/serf-1 by default, too.
On Sun, Jun 16, 2013 at 5:35 AM, Christopher Meng cickumqt@gmail.com wrote:
Hi,
I'm packaging serf into Fedora.
Here is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=973904
However, the reviewer said that this package should follow how was packaged in oter distros.
Debian and OpenSUSE install headers to /usr/include/serf-1/*.h, but I just packaged them to /usr/include/*.h
Now I decide to install them to a new folder, should I keep updated with Debian or OpenSUSE, and install them to /usr/include/serf-1/, or to /usr/include/serf/?
Thanks.
Yours sincerely, Christopher Meng
serf is a relatively new library: I know that the next planned version of Subversion, version 1.8, plans to use it instead of the older "neon" librar, and they're excited aobut its performance benefits, so it behooves us to to make sure it's available. Putting it in "/usr/include/serf" or something like it would have made a lot more sense if the *upstream* authors had done so. They didn't, and that means that every application probing for it is going to have to have autoconf detect a new, non-author-specified include file location.
That said, it's not unreasonable to be consistent with other RPM based distributions.. It is going to break *every single RPM* that does not have its autoconf or other configuration tools configured to add -I/usr/include/serf-1.
packaging@lists.fedoraproject.org
-
Christopher Meng -
Michael Schwendt -
Nico Kadel-Garcia -
Remi Collet