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