[Bug 494148] Review Request: soci - The database access library for C++ programmers

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=494148





--- Comment #6 from Denis Arnaud <denis.arnaud_fedora at m4x.org>  2009-04-06 12:59:57 EDT ---
(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!

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.