[Bug 474787] Review Requrest: stxxl - C++ STL drop-in replacement for extremely large datasets

bugzilla at redhat.com bugzilla at redhat.com
Mon Jun 1 01:32:17 UTC 2009


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=474787





--- Comment #12 from Denis Arnaud <denis.arnaud_fedora at m4x.org>  2009-05-31 21:32:15 EDT ---
[My machine crashed just before I pressed the commit button of the review :( ]

Note that, as I have not the sponsor status, that is not an official review.
However, there are a number of issues (some important, some others less) that I
can point to you (in no particular order).

1. Doxygen, as it is configured, generates .map files (in the doc/html
sub-directory), due to the use of the DOT tool (belonging to the graphviz
package). On some configurations (e.g., my Fedora rawhide/11, with rpmbuild),
some of those files are generated with a zero-length, which rpmlint then
complains of.

There are, at least, two solutions/work-arounds:
  1.a. Just drop the use of DOT in the Doxygen configuration file:
  HAVE_DOT = NO
  as in
http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/doc/doxygen_html.cfg.in?revision=183&view=markup
  As Doxygen replaces with other, simpler, diagrams, that should not be a so
big issue.
  1.b. Keep the use of DOT, but:
    - Add a 'BuildRequires: graphivz' directive.
    - Remove any zero-length-map files after the Doxygen generation
(http://cvs.fedoraproject.org/viewvc/rpms/asterisk/F-11/asterisk.spec?revision=1.51&view=markup):
      find doc/html -name '*.map' -size 0 -delete

Note that with mock, there is, as is, no zero-length-map-file issue, but the
.map files are not generated, due to the missing 'BuildRequires: graphviz'
directive. Note also that you can not see that in the build.log
(http://koji.fedoraproject.org/koji/getfile?taskID=1383290&name=build.log) of
Koji, as you have re-directed the output log of Doxygen into a file removed by
mock.

2. Avoid re-directing the output log of Doxygen, so that that log be present in
the build.log generated by mock (and Koji):
make doxy > doxymake.log 2> doxymake.stderr
==>
make doxy

3. You may consider creating a separate -doc sub-package for both the HTML
Doxygen-generated documentation and the Latex-generated tutorial
(https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation).

4. I would rather keep the PDF version of the tutorial, rather than the DVI
one. Moreover, we could alter the Makefile so that it generates only the PDF
version (which is now the default with latex).

5. In the %files section, you should take ownership of the %{_includedir}/bits
directory
(https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership):
%dir %{_includedir}/bits/

6. Still in the %files sections, it may be better to use a wildcard for the
libraries, as it will still hold for future versions of the library:
%{_libdir}/libstxxl.so.*

7. You may replace instances of stxxl with the %{name} macro, and of 1.2.1 with
the %{version} macro
(https://fedoraproject.org/wiki/Packaging/Guidelines#Macros). For instance:
---------------------------------------------------
URL:     http://%{name}.sourceforge.net
Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
Patch0:  %{name}-build-shared.patch
Patch1:  %{name}-build-shared-makefile.patch
---------------------------------------------------

x. The build system (makefiles) appears to be very specific to that package,
and it may not be portable. For instance, you have to install the files
manually yourself in the specification file. If you consider to bring a GNU
Autotools environment (and submit the corresponding patch upstream), and if I
can help you, do not hesitate.

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




More information about the Fedora-package-review mailing list