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@xxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review