* 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 (http://sourceforge.net/projects/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 http://soci.sourceforge.net) and have integrated it into a sub-repository of my own OpenTREP project (http://opentrep.svn.sourceforge.net/viewvc/opentrep/trunk/soci/), 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"?
http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_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?

> 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.

http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

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"?

https://fedoraproject.org/wiki/Packaging/UnownedDirectories

$ 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).

> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
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: http://boost-extras.sourceforge.net/gnu-boost/gnu-boost.html
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 (http://packages.qa.debian.org/s/soci.html and http://packages.debian.org/source/sid/soci), 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, http://sourceforge.net/projects/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 (http://downloads.sourceforge.net/soci/soci-3.0.0.tar.gz) of the SOCI project (http://soci.sourceforge.net).

The updated files are:
Spec URL: http://downloads.sourceforge.net/opentrep/soci.spec?use_mirror=ovh
SRPM URL:
http://downloads.sourceforge.net/opentrep/soci-3.0.0-3.fc10.src.rpm?use_mirror=ovh

----------------------------------------

* 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.

* A full build has been made on Koji for i386 (http://koji.fedoraproject.org/koji/taskinfo?taskID=1296097) and x86_64 (http://koji.fedoraproject.org/koji/taskinfo?taskID=1296088) architectures. SRPMs can be fetched there as well.

* rpmlint gives no error and no warning (on the specification file, as well as on source RPM and binary RPM packages).
---------------------------------------

Thanks in advance for your feedback.

The RPM packaging is now fully based on the pristine version 3.0.0 (http://downloads.sourceforge.net/soci/soci-3.0.0.tar.gz) of the SOCI project (http://soci.sourceforge.net).
[And I have created a "soci-3.0.0" branch on my own Subversion repository within the OpenTREP project (http://opentrep.svn.sourceforge.net/viewvc/opentrep/branches/soci-3.0.0/), so as to allow further evolutions upstream (on the trunk)]

The updated files are:
Spec URL: http://downloads.sourceforge.net/opentrep/soci.spec?use_mirror=ovh
SRPM URL: http://downloads.sourceforge.net/opentrep/soci-3.0.0-3.fc10.src.rpm?use_mirror=ovh
----------------------------------------
 
* 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).

* A full build has been made on Koji for i386
(http://koji.fedoraproject.org/koji/taskinfo?taskID=1302910) and x86_64
(http://koji.fedoraproject.org/koji/taskinfo?taskID=1302916) architectures.
SRPMs can be fetched there as well.
 
* rpmlint gives no error and no warning (on the specification file, as well as
on source RPM and binary RPM packages).
---------------------------------------

I now wait for your feedback/approval.

The files have been moved onto http://denisarnaud.fedorapeople.org:
Spec URL: http://denisarnaud.fedorapeople.org/soci.spec
SRPM URL: http://denisarnaud.fedorapeople.org/soci-3.0.0-3.fc10.src.rpm

[Patch URLs: http://denisarnaud.fedorapeople.org/soci-3.0.0-fix-gcc43-compatibility.patch and http://denisarnaud.fedorapeople.org/soci-3.0.0-fix-gnu-autotools-compatibility.patch ]

The patches have been submitted upstream. The developer team seems happy with that initiative: http://mateusz.loskot.net/2009/04/17/soci-300-rpm-packages/

* 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: http://denisarnaud.fedorapeople.org/soci.spec
SRPM URL: http://denisarnaud.fedorapeople.org/soci-3.0.0-4.fc10.src.rpm

[Patch URLs:
http://denisarnaud.fedorapeople.org/soci-3.0.0-fix-gcc43-compatibility.patch
and
http://denisarnaud.fedorapeople.org/soci-3.0.0-fix-gnu-autotools-compatibility.patch has been updated
]  

And the corresponding Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1306924 (i586) and http://koji.fedoraproject.org/koji/taskinfo?taskID=1306926 (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., https://sourceforge.net/mailarchive/forum.php?thread_name=b4f0e550904170119g70dd673fo3393ad0b01a9a7eb%40mail.gmail.com&forum_name=soci-users), part of which have already been applied by the SOCI developer team.

Further patches (on top of the CVS trunk version) are available here: http://denisarnaud.fedorapeople.org/cvstrunk/ , 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 (http://soci.sourceforge.net), I have created a new project, namely Extras-SOCI (http://sourceforge.net/projects/extras-soci), which aims to be for SOCI what Extras Boost (http://boost-extras.sourceforge.net/) 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: http://denisarnaud.fedorapeople.org/extras-soci/extras-soci.spec
SRPM URL: http://denisarnaud.fedorapeople.org/extras-soci/extras-soci-3.1.0-1.fc10.src.rpm

And the corresponding Koji builds:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1320781 (i586) and
http://koji.fedoraproject.org/koji/taskinfo?taskID=1320788 (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: http://denisarnaud.fedorapeople.org/pristine300/soci.spec
SRPM URL: http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-4.fc10.src.rpm

[Patch URLs:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gcc43-compatibility.patch
and
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gnu-autotools-compatibility.patch
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 (http://soci.sourceforge.net) 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: http://denisarnaud.fedorapeople.org/extras-soci/extras-soci.spec
SRPM URL:
http://denisarnaud.fedorapeople.org/extras-soci/extras-soci-3.1.0-2.fc10.src.rpm

And the corresponding Koji builds:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1321640 (i586) and
http://koji.fedoraproject.org/koji/taskinfo?taskID=1321642 (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: http://denisarnaud.fedorapeople.org/pristine300/soci.spec
SRPM URL:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-4.fc10.src.rpm

[Patch URLs:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gcc43-compatibility.patch
and
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gnu-autotools-compatibility.patch
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: http://denisarnaud.fedorapeople.org/pristine300/soci.spec
SRPM URL:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-5.fc10.src.rpm

[Patch URLs:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gcc43-compatibility.patch (same file as before)
and
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gnu-autotools-compatibility.patch (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: http://denisarnaud.fedorapeople.org/pristine300/soci.spec
SRPM URL:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-6.fc10.src.rpm

[Patch URLs:
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gcc43-compatibility.patch
(same file as before)
and
http://denisarnaud.fedorapeople.org/pristine300/soci-3.0.0-fix-gnu-autotools-compatibility.patch
(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.
http://admin.fedoraproject.org/updates/soci-3.0.0-6.fc10

soci-3.0.0-10.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/soci-3.0.0-10.fc11

soci-3.0.0-10.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/soci-3.0.0-10.fc10

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):
http://koji.fedoraproject.org/koji/getfile?taskID=1337938&name=build.log
and http://koji.fedoraproject.org/koji/getfile?taskID=1337898&name=build.log .


For EL-5, there seems to be an old issue (bug 227790) on having a noarch sub-package: http://buildsys.fedoraproject.org/logs/fedora-5-epel/2188-soci-3.0.0-12.el5/noarch/build.log :
----------------------------------------------------------------
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: Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/libsoci_core.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_core.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_core.so.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.debug
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/libsoci_core.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_core.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_core.so.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_mysql.so.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.3.0.0.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.3.debug
   /usr/lib/debug/usr/lib64/libsoci_postgresql.so.debug
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: http://koji.fedoraproject.org/koji/taskinfo?taskID=1338113

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).