text: Red Hat Bugzilla – Bug 494148
  Review Request: soci - The database access library for C++ programmers
  Last modified: 2014-09-11 07:57:44 EDT
  Spec URL:
  SRPM URL:
  Description: [FE-NEEDSPONSOR] That is my second package for Fedora, and I thus
  still need a sponsor.
  ------------------------------------------------
  The database access library for C++ programmers provides the
  illusion of embedding SQL in regular C++ code, staying entirely within
  the C++ standard.
  Web site:
  ------------------------------------------------
  * For all -devel sub-packages change "BuildRequires" to "Requires", because you want the builds to depend on the {mysql,sqlite,postgresql}-devel packages. Plus, add the missing "Requires: %name-devel = %version-%release" as the core soci headers are needed.
  * For the optional Oracle Database builds, consider adding a conditional build parameter (see /usr/share/doc/rpm-*/conditionalbuilds), so you could simple build "--with oracle" to enable the optional packages instead of having to edit the spec file.
  * The package %description does not mention the project name "SOCI" anywhere.
  * Why is the tarball not downloaded from the soci.sf.net download location but from your opentrep project space? It differs by ~4MiB. Where does that tarball come from? Is it a checkout from a source code management system? In that case you need to follow the guidelines for 1) documenting this in the spec file, and 2) proper pre-/post-release package versioning.
  * Package (except for the MySQL backend) doesn't adhere to the compiler flags guidelines.
  * Directory %{_includedir}/%{name}/backends/ is not included.
  > %package devel
  > [...]
  > Requires(post): info
  > Requires(preun): info
  "info" is not used. -devel package doesn't contain any post/preun scriptlet.
  (In reply to comment #1)
  * Short answer: I shall implement all the required changes, as soon as I can.
  * Longer answer:
  - As I use SOCI in several projects, some of them being open source, I would need to have SOCI officially (eventually) integrated within Fedora to be able to submit, among those projects, the Fedora-compatible ones. For instance, I am the "owner" of OpenTREP (), which relies on SOCI, and I would like to eventually submit OpenTREP for Fedora inclusion.
  - As the SOCI project has not been designed with packaging requirements in mind, the code base needs a lot of structure re-work. For instance:
  * The C++ header files are, by default, all delivered in /usr/include (without any further structure), and assumed to be installed that way when integrated in other programs.
  * The build system is very specific: there is a "configure" script, but absolutely not the classical (from the GNU autotools suite) one, and a few "hard-coded" makefiles.
  * Both the directories for the header files and the libraries must be specified at "configure" time.
  * A few includes are missing for SOCI to compile with g++ from version 4.3 onwards.
  * The delivered dynamic libraries do not contain sonames.
  * The test directories are not designed to be executed by the "make check" command.
  - SOCI integrates, by default, some database backends (namely, Oracle, Microsoft ODBC and Firebird), which either do not comply with Fedora policy (e.g., Oracle and Microsoft ODBC are proprietary software, even though there is a Unix equivalent for ODBC) or have not been integrated within Fedora (e.g., Firebird). Those backends must be de-activated within Fedora.
  - I have proposed to the project owners (through the mailing list) to help them package SOCI within Fedora, but they (constantly) did not react. However, a few members of the (SOCI developer) mailing list showed their interest in my packaging project. So, it should prove useful not only for my own projects.
  - Given the above, I have thus copied version 3.0.0 of the code (available under the Boost license on) and have integrated it into a sub-repository of my own OpenTREP project (), to benefit from a stable environment on which I can work everything easily out. I have patched the code as little as possible (mainly for g++ from version 4.3 onwards compatibility), and I have focused on adding the structure for a classical delivery and packaging process (mainly, GNU Autotools addition).
  - While this was not intended, the above means, on a formal point of view, that I did a fork of the code from version 3.0.0, even though I intended to re-integrate all the changes from the SOCI actual trunk (CSV repository) to my own repositories.
  - For maintainability reasons, I shall strive, however, to operate the classical way, that is, base the package on the actual SOCI codebase, and just bring patches, so that eventually the package can be delivered cleanly in a Fedora-compatible way. But, there is still some work to do before achieving that...
  Thanks for your feedback. I'll keep you updated (it should still take a few days until I can post a new version of the packaging process).
  (In reply to comment #1)
  Still from the fork, I have fixed a few issues you had identified, and have replaced the Source RPM, tar-balls and specification file.
  > * For the optional Oracle Database builds, consider adding a conditional build
  > parameter (see /usr/share/doc/rpm-*/conditionalbuilds), so you could simple
  > build "--with oracle" to enable the optional packages instead of having to
  > edit the spec file.
  Done.
  > * The package %description does not mention the project name "SOCI" anywhere.
  Done.
  > * Package (except for the MySQL backend) doesn't adhere to the compiler flags
  > guidelines.
  The "configure" now reads:
  %configure --disable-static \
  %{?_with_mysql} %{?_without_mysql} \
  %{?_with_postgresql} %{?_without_postgresql} \
  %{?_with_sqlite} %{?_without_sqlite} \
  %{?_with_oracle:%{?_with_oracle} %{?_with_oracle_incdir} %{?_with_oracle_libdir}} \
  %{?_without_oracle}
  make %{?_smp_mflags}
  It seems to work well. What did you mean by "Package does not adhere to the compiler flag guidelines"?
  > * Directory %{_includedir}/%{name}/backends/ is not included.
  The main -devel package (namely, soci-devel) contains the "empty" backend, and thus includes the %{_includedir}/%{name}/backends/empty directory. However, since there may be other backend include directories at the building time, only the backend/empty sub-directory should be taken in charge by the main -devel package.
  The other -devel sub-packages (namely, soci-{mysql,postgresql,sqlite,oracle}-devel) each includes the correspnding %{_includedir}/%{name}/backends/{mysql,postgresql,sqlite3,oracle} directory.
  What did you mean by "Directory %{_includedir}/%{name}/backends/ is not included"?
  > > %package devel
  > > [...]
  > > Requires(post): info
  > > Requires(preun): info
  >
  > "info" is not used. -devel package doesn't contain any post/preun scriptlet.
  Right. Removed.
  Moreover, as said in comment #2, I'll shortly work on starting from the genuine SOCI codebase (only adding patches) instead of starting from my "technical fork".
  (In reply to comment #3)
  > It seems to work well. What did you mean by "Package does not adhere to the
  > compiler flag guidelines"?
  How can I override the compiler flags, so as to use $RPM_OPT_FLAGS/%{optflags}? Should I add something like CPPFLAGS="%{optflags}" in the %configure macro?
  > on a formal point of view,
  > that I did a fork of the code from version 3.0.0
  This asks for trouble. At least Debian and Mandriva ship packages of SOCI, albeit an older release as it seems.
  Making up SONAMEs and modifying the ABI and API (header location for default include paths) typically is frowned upon.
  Remains the question whether it would be more convenient for you to rename the project at least slightly?
  The "empty" and SQLite backends are not included in the upstream 3.0.0 release. The diff between pristine 3.0.0 and your tarball is ~4 MB, not just due to adding the autotools framework.
  > there is a "configure" script, but
  > absolutely not the classical (from the GNU autotools suite) one,
  You need not use the %configure macro, if the available "configure" is a custom one that is incompatible. Could the SOCI configure script be used directly? Or would it need to be patched heavily (it's just 2K) to do a good job?
  > What did you mean by "Directory %{_includedir}/%{name}/backends/
  > is not included"?
  $ diff -u soci.spec.orig soci.spec
  --- soci.spec.orig 2009-04-05 10:43:01.000000000 +0200
  +++ soci.spec 2009-04-06 16:11:59.000000000 +0200
  @@ -222,6 +222,7 @@
  %doc ABOUT-NLS AUTHORS ChangeLog COPYING NEWS README
  %dir %{_includedir}/%{name}
  %{_includedir}/%{name}/core
  +%dir %{_includedir}/%{name}/backends
  %{_includedir}/%{name}/backends/empty
  %{_bindir}/%{name}-config
  %{_libdir}/lib%{name}_core.so
  > What did you mean by "Package does not adhere to the
  > compiler flag guidelines"?
  That only the MySQL backend uses Fedora's global optflags during compilation. The rest of the code builds with other flags.
  > How can I override the compiler flags, so as to use
  > $RPM_OPT_FLAGS/%> {optflags}?
  > Should I add something like CPPFLAGS="%{optflags}" in
  > the %configure macro?
  Run "rpm --eval %configure" to see what the macro does. It exports CXXFLAGS, so all you would need to do is make sure all Makefiles inherit $CXXFLAGS (which would be the default with automake/autoconf unless you override the flags in a way that doesn't accept CFLAGS/CXXFLAGS if passed in from the environment).
  (In reply to comment #5)
  Thanks for your comments, things appear clearer now.
  > This asks for trouble. At least Debian and Mandriva ship packages of SOCI,
  > albeit an older release as it seems.
  The last Mandriva package for SOCI was for version 2.2.0. However, I've noticed that version 3.0.0 has just landed this morning on Debian unstable:
  - They (Debian packagers) also deliver a structured directory framework for the header files, but not exactly the same I chose (theirs exposes the different backend types directly in the /usr/include/soci directory: /usr/include/soci/mysql for instance).
  - For the libraries, they deliver renamed shared libraries like:
  /usr/lib/libsoci_core-gcc-3_0.so -> libsoci_core-gcc-3_0-3.0.0.so
  and the soname is libsoci_core-gcc-3_0-3.0.0.so (so, there is one).
  >
  You are right: I'll work on the upstream version.
  > Making up SONAMEs and modifying the ABI and API (header location for default
  > include paths) typically is frowned upon.
  - For the header files, you may have noticed that I now also deliver the header files in a compatible way with the genuine SOCI package (every header file is delivered both directly in the %{_includedir}/%{name} directory and in the corresponding hierarchy, for instance %{_includedir}/%{name}/backends/mysql).
  - For the SONAME, it seems to me cleaner to have one.
  > Remains the question whether it would be more convenient for you to rename the
  > project at least slightly?
  That is definitely an option. However, I'll first try to stick to the genuine SOCI upstream codebase, albeit with GNU Autotools, much like GNU Boost:
  If I cannot make it, I'll fall-back to a modified version.
  > The "empty" and SQLite backends are not included in the upstream 3.0.0 release.
  Hmmm, you are right. Those backends may have been added afterwards. I added them for convenient reasons, but it means that my release is half-way between 3.0.0 and head of trunk, which is not good. Again, if I work directly from the pristine SOCI-delivered codebase, that issue should be solved.
  > The diff between pristine 3.0.0 and your tarball is ~4 MB, not just due to
  > adding the autotools framework.
  To be accurate:
  $ du -ks soci*
  1616 soci-3.0.0
  3808 soci4pack-3.0.0
  It seems that the main difference comes from the fact that I've added i18n (NLS) support (PO files and makefiles). It may prove to be useful for the i18n support of SOCI (for instance, within Fedora).
  > You need not use the %configure macro, if the available "configure" is a
  > custom one that is incompatible. Could the SOCI configure script be used
  > directly? Or would it need to be patched heavily (it's just 2K) to do a
  > good job?
  The native "configure" file is a (very) small Shell script, in turn calling a few TCL commands. Moreover, the makefiles have been manually written, having for consequence that:
  - the include and library directories must be specified, whatever value they have, just to activate the corresponding backends, for instance:
  ./configure --include-prefix=/usr/include/soci --lib-prefix=/usr/lib --mysql-include=/usr/include/mysql --mysql-lib=/usr/lib/mysql);
  - each time a "make" is launched, all the source code is recompiled (no detection of dependencies).
  So, using that "configure" script would mean hardcoding many file-pathes in the RPM specification file.
  Thanks again for your valuable feedback and input. I've still a lot of work ahead!
  > The diff between pristine 3.0.0 and your tarball is ~4 MB
  I referred to "diff -Nur ..." of the two tarballs. The diff between the soci upstream tarball and the soci subdir in your tarball is still ~2 MB. In either case, this package is not SOCI 3.0.0 as found on their project site. ;-)
  > For the SONAME, it seems to me cleaner to have one.
  True, but upstream ought to be involved in deciding which soname to start with _and_ which major library version to include in the soname.
  Debian's soname scheme breaks the ABI everytime the library version and/or compiler version is changed. With your own soname scheme, the burden of maintaining ABI stability is solely on your shoulders.
  $ rpm -qp --provides soci-mysql-3.0.0-2.fc10.i386.rpm | grep ^lib
  libsoci_mysql.so.3
  Plus, there is the risk that a future upstream release will conflict with your sonames and soname versions. Perhaps they will restart at .so.3 while you are at .so.4 already. Perhaps they will start at .so.0 or .so.1 for the first stable API.
  If sonames are made up, it's better to include the full product version in the soname (e.g. libsoci_mysql-3.0.0.so.0 <- libsoci_mysql-3.0.0.so), which will require rebuilds of dependencies everytime the version changes.
  Consider joining forces with the Debian package maintainer.
  (In reply to comment #7)
  > Consider joining forces with the Debian package maintainer.
  I've sent an email to Debian QA team for that purpose. However, since that package has been orphaned ( and), there is no longer an individual maintainer for it.
  Once I'll have a pristine SOCI v3.0.0-derived Fedora-compliant package, I'll talk again with the upstream development team, in order to see whether (at least) SONAME can be added.
  Right now, with the RPM packages I delivered, software using SOCI (for instance, OpenTREP,) works almost seamlessly on both installations (either RPM-based or pristine one). So, it should not be a burden for them (SOCI developer team) to accept a few changes so that packages can be cleanly prepared for the major Linux distributions.
  The RPM packaging is now based on the pristine version 3.0.0 () of the SOCI project ().
  The updated files are:
  Spec URL:
  SRPM URL:
  ----------------------------------------
  * As the HTML documentation is present in the pristine tar-ball, I have kept the corresponding files, but converted them into Doxygen-generated documentation. And, as SourceForge teams require that their logo be present on the hosted Web site, I've added it in the sources.
  * Moreover, the general "GNU Autotools compatibility" patch could certainly be split into a few more specific patches, if needed. In fact, I first wanted to see whether I was back on the right track before pushing for some more refinements.
  *).
  ---------------------------------------
  Thanks in advance for your feedback.
  The RPM packaging is now fully based on the pristine version 3.0.0 () of the SOCI project ().
  [And I have created a "soci-3.0.0" branch on my own Subversion repository within the OpenTREP project (), so as to allow further evolutions upstream (on the trunk)]
  The updated files are:
  Spec URL:
  SRPM URL:
  ----------------------------------------
  * The HTML documentation is now just copied into %{docdir}, without further process.
  * Moreover, the general "GNU Autotools compatibility" patch now only contains configure files and makefiles (and alters those existing in the pristine tar-ball).
  *).
  ---------------------------------------
  I now wait for your feedback/approval.
  The files have been moved onto:
  Spec URL:
  SRPM URL:
  [Patch URLs: and ]
  The patches have been submitted upstream. The developer team seems happy with that initiative:
  * I'll try to take a look at the latest rpms this weekend.
  * Fedora's optflags guidelines are still not adhered to -- only the mysql backend uses them.
  * Since you've made ##heavy## use of _with/_without, you might be interested in learning about the %bcond_with/%bcond_without macros. See section "Conditional build stuff" in /usr/lib/rpm/macros.
  (In reply to comment #13)
  > * Fedora's optflags guidelines are still not adhered to -- only the mysql
  > backend uses them.
  I have fixed the configure.ac file: the CXXFLAGS was copied into CXXFLAGS_OPT and then set to void. In the other side, the MySQL backend was compiled with the correct flags, because that was what the `mysql_config --cflags` command returned. But that latter may not be portable/consistent across all the platforms.
  The new configure.ac file does no longer override the CXXFLAGS, and I have changed the ax_{mysql,postgresql}.m4 files, so that the cppflags only add the "-I${includedir}" option when appropriate.
  The updated files are here:
  Spec URL:
  SRPM URL:
  [Patch URLs:
  and has been updated
  ]
  And the corresponding Koji build: (i586) and (x86_64)
  > * Since you've made ##heavy## use of _with/_without, you might be interested in
  > learning about the %bcond_with/%bcond_without macros. See section "Conditional
  > build stuff" in /usr/lib/rpm/macros.
  I have read that section, and it may help reduce a little bit my usage of _with/_without. Still, I have to figure how to replace part of those latter with the %bcond_with/%bcond_without macros.
  Some patches (on top of the CVS trunk version) have been submitted upstream (e.g.,), part of which have already been applied by the SOCI developer team.
  Further patches (on top of the CVS trunk version) are available here: , and have been submitted upstream. Discussions are on-going for their integration.
  The patches on top of the version 3.0.0 have been welcomed by the SOCI developer team: the RPM packages can therefore be generated for the version 3.0.0 of SOCI.
  As it was almost impossible to contribute "additively" to the SOCI project (), I have created a new project, namely Extras-SOCI (), which aims to be for SOCI what Extras Boost () is for Boost, that is:
  * wrap the pristine SOCI source code within standard GNU framework (Autotools, i18n, Manual & Info pages, etc.);
  * host the project on a Subversion repository;
  * welcome any contribution;
  * synchronise with the SOCI code base, every time that latter evolves (once every six month, more or less).
  Hence, I shall deliver RPM packages for extras-soci, synchronised with the code base of SOCI. That is, there will be extras-soci-3.0.0 and extras-soci-cvstrunk fully compatible with respectively soci-3.0.0 and soci-cvstrunk.
  Should I close that review report and open a new one for extras-soci? Or is that fine to keep that one for releasing extras-soci packages?
  Thanks in advance for your feedback.
  The files for the new Extras-SOCI project are as following:
  Spec URL:
  SRPM URL:
  And the corresponding Koji builds: (i586) and (x86_64)
  Those files correspond to the CVS trunk version of SOCI, i.e., when installing those RPM packages, we install the latest version of the SOCI library (and header files).
  -----------------------------------------------------------------------------
  Note: for the (pristine) version 3.0.0 of SOCI, the files have been moved to the following location, and are still valid:
  Spec URL:
  SRPM URL:
  [Patch URLs:
  and
  has been updated
  ]
  [As that release (pristine 3.0.0 version) is fully based on the official release of the SOCI library, they are not hosted by the Extras-SOCI project]
  -----------------------------------------------------------------------------
  * About the %bcond_ macros, they shorten the setup of the conditional builds in the spec file. Compared with what you do currently (evaluate the --with/--without options, set a default if neither one is defined, throw an error if both are defined, overwrites the values with options to pass to %configure), it would reduce to
  # Defaults:
  %bcond_with empty
  %bcond_without mysql
  %bcond_without postgresql
  %bcond_with sqlite3
  %bcond_with odbc
  %bcond_with firebird
  %bcond_with oracle
  %bcond_without nls
  where all lines with "_with" are for features that are off by default and all with "_without" are enabled by default. You can toggle these defaults simply by replacing "with" with "without" and vice versa. No other changes (such as evaluating _with/_without vars or reordering assignment of defaults) are necessary. You query the features like:
  %configure ...
  %if %{with foo}
  --enable-backend-foo \
  %else
  --disable-backend-foo \
  %endif
  %if ! %{with foo}
  # feature "foo" is disabled
  # do something
  %endif
  %if %{with foo}
  %package foo
  ...
  %endif
  %{?with_foo:BuildRequires: foo-devel}
  More examples in the RPM macros definition file.
  * Something has truncated/damaged the extras-soci-doc package. It's down to 57KB with an empty main page and only a very few pages that either contain not much or broken links to non-existent files.
  * The soci -> extras-soci rename is incomplete:
  $ extras-soci-config --libs
  -lextras-soci
  $ pkg-config --libs extras-soci
  -lextras-soci_core
  $ rpm -ql extras-soci-devel|grep \.so$
  /usr/lib/libsoci_core.so
  Plus, currently, even without renamed libs, the extras-soci* packages would conflict with an installation made with the pristine SOCI tarballs. One could make the packages conflict explicitly using proper "Conflicts: ..." tags, but they are not compatible/interchangable either due to the renamed files (e.g. the pkg-config file, the M4 macro file, the -config script).
  Do you want all the extras-soci* packages to be parallel installable with any soci* package somebody may add to the dist? Do you want them to become alternatives, i.e. interchangable and ABI+API compatible?
  Thanks for your feedback!
  1. %bcond_with: I've integrated your suggestions. The result is indeed much more compact... and readable! Thanks.
  2. (HTML) doc package: the doc/doxygen.cfg still incorporated the ${src_topdir}/extras-soci source code directory, instead of ${src_topdir}/soci. It has now been fixed. The full API (and source code) is now accessible, and the main page (index.html) now reproduces the content of the SOCI project () main page. The links were broken because the HTML pages in the doc/local directory had not been migrated to SGML format for Doxygen to take it into account. I've migrated those files.
  3. soci -> extras-soci renaming is now fine for extras-soci-config and pkg-config scripts.
  4. (Potential) conflicts with any soci* package. If somebody else wants to deliver soci* packages, he or she will be more than welcome (!), and we should join our forces, so that there remain a single set of packages. So, if somebody reaches a point where a soci* set of packages is fully supported by the SOCI developer team, that new set of packages will of course deprecate mine, and that will be an happy end :) And I shall be happy to contribute to that, of course!
  In summary, I do not intend the extras-soci* packages to be parallel installable with any soci* package somebody may add to the distribution. The extras-soci* packages do intend to provide SOCI-compatible (ABI+API) libraries.
  ------------------------------------------------------------------------
  The updated files for the Extras-SOCI project are as following:
  Spec URL:
  SRPM URL:
  And the corresponding Koji builds: (i586) and (x86_64)
  ------------------------------------------------------------------------
  To be clear, I just ask for approval for the packaging of the pristine SOCI version 3.0.0 (i.e., the lastest release). The corresponding files are still here:
  -----------------------------------------------------------------------------
  Spec URL:
  SRPM URL:
  [Patch URLs:
  and
  has been updated
  ]
  -----------------------------------------------------------------------------
  On the other hand, the extras-soci project is, for now, rather a proof-of-concept for later releases of SOCI (if any!), and a framework for easy patching (for instance, the test programs for the ODBC and Firebird backends do not compile in the pristine CVS trunk), before those patches are incorporated upstream. Of course, no RPM package should be released for later versions (> 3.0) of SOCI, as those do not exist yet... When the upstream developer team will make new releases, the extras-soci project will be ready to package those, after the synchronisation of the source code with the pristine tar-ball. At that time, I shall of course ask again for review and approval.
  -----------------------------------------------------------------------------
  I have just "back-ported", on one of the 3.0.0 patches and on the specification file, the work you suggested on the building switches (%bcond macros in the specification file):
  -----------------------------------------------------------------------------
  Spec URL:
  SRPM URL:
  [Patch URLs: (same file as before)
  and (has been updated)
  ]
  -----------------------------------------------------------------------------
  > soci-3.0.0-5.fc10.src.rpm
  APPROVED
  So you can squash remaining issues in pkg cvs, which will be more convenient than going through the upload-bugzilla-review cycle.
  [...]
  With a caveat, though, as the conditional build options don't seem to work [yet]:
  configure: WARNING: unrecognized options: --disable-backend-empty, --disable-backend-sqlite3
  And although it recognises the other --disable-backend options, it ignores them and still builds various backends if the needed -devel pkgs are installed. E.g. --without mysql ends with RPM build errors:
  Installed (but unpackaged) file(s) found:
  /usr/include/soci/backends/mysql/soci-mysql.h
  /usr/lib/libsoci_mysql.so
  /usr/lib/libsoci_mysql.so.3
  /usr/lib/libsoci_mysql.so.3.0.0
  Unless you can disable the backends at "configure"-time, you could add "BuildConflicts: mysql-devel" to enforce uninstalling unwanted -devel pkgs. ;o)
  [...]
  > %define mydocs __tmp_docdir
  Not used anywhere.
  * The many %{?with_foo:...} switches throughout the spec file could be grouped together and could be replaced with a much more readable %if/%endif block that covers everything for each conditional subpkg except the %build/%install sections. In other words, for e.g. MySQL you would end up with:
  %if %{with mysql}
  %package mysql
  ...
  %description mysql
  ...
  %files mysql
  ...
  %post mysql -p /sbin/ldconfig
  %postun mysql -p /sbin/ldconfig
  ...
  %package mysql-devel
  ...
  %description mysql-devel
  ...
  %files mysql-devel
  ...
  %endif
  New Package CVS Request
  =======================
  Package Name: extras-soci
  Short Description: The database access library for C++ programmers
  Owners: denisarnaud
  Branches: F-10 F-11 F-12 EL-5
  InitialCC: denisarnaud
  Uh, extras-soci?
  Sorry! The new package request if for SOCI (pristine version 3.0.0), not extras-soci!
  The last modifications you suggested are on their way (a few checks, and I shall upload it on fedorapeople.org).
  -------------------------------------------------------
  New Package CVS Request
  =======================
  Package Name: soci
  Short Description: The database access library for C++ programmers
  Owners: denisarnaud
  Branches: F-10 F-11 F-12 EL-5
  InitialCC: denisarnaud
  -------------------------------------------------------
  I've taken that opportunity to re-deliver a 6th version of the RPM specification file:
  ------------------------------------------------------------------------
  Spec URL:
  SRPM URL:
  [Patch URLs:
  (same file as before)
  and
  (has been updated)
  ]
  ------------------------------------------------------------------------
  The conditional builds are now fine for all the backend types (MySQL, PostGreSQL and Oracle).
  For Oracle, though, I should add a conditional build switch for every major version (9, 10 and 11), as the Oracle client library has hard-coded that version within its name (e.g., -lnnz11 for version 11). But on Fedora, I guess that that is not an issue (due to license problems): it will occur only for non-free repositories.
  As there are now less conditional build flags, I'll apply your suggestion (having a single switch by backend type) on the extras-soci package (after having played with it), rather than on the pristine one.
  cvs done.
  soci-3.0.0-6.fc10 has been submitted as an update for Fedora 10.
  soci-3.0.0-10.fc11 has been submitted as an update for Fedora 11.
  soci-3.0.0-10.fc10 has been submitted as an update for Fedora 10.
  For Fedora 10 and 11, it builds cleanly, as well as for rawhide on i586 and x86_64.
  However, on rawhide ppc/ppc64, there seems to be stability problems (e.g., problem with the build/libtool tool on that platform for that version):
  and .
  For EL-5, there seems to be an old issue (bug 227790) on having a noarch sub-package: :
  ----------------------------------------------------------------
  Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
  Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/soci-3.0.0-12.el5-root-mockbuild
  error:
  RPM build errors:
  Child returncode was: 1
  ----------------------------------------------------------------
  If you know of a work around, do not hesitate to tell me :)
  RPM on EL5 cannot do noarch subpkgs. That's a new feature in RPM for Fedora >= 10. To reuse the same spec file, you could do:
  %if 0%{?fedora} >= 10
  BuildArch: noarch
  %endif
  Note that there are further macros like that. Mentioned on the DistTag guidelines page in the Wiki.
  [...]
  F-12 devel:
  ppc also ran into an internal compiler error. If that will happen again, it may need a bug report.
  The ppc64/ppc build triggers automatic autotools reconfiguration, which then fails just like a manual "autoreconf -f". Could be related to how you've created your fix-gnu-autotools-compatibility patch and what versions of the autotools you've used.
  A quick work-around was to run "autoreconf ; libtoolize -c -f" at the end of %prep:
  soci-3.0.0-6.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
  soci-3.0.0-10.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
  soci-3.0.0-10.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
  Package Change Request
  ======================
  Package Name: soci
  New Branches: el7
  Owners: denisarnaud
  Git done (by process-git-requests).