[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 #2 from Denis Arnaud <denis.arnaud_fedora at m4x.org>  2009-04-05 15:18:21 EDT ---
(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).

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