[Bug 366121] Review Request: httrack - Website copier and offline browser

bugzilla at redhat.com bugzilla at redhat.com
Sat Nov 10 14:39:42 UTC 2007


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

Summary: Review Request: httrack - Website copier and offline browser


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


mtasaka at ioa.s.u-tokyo.ac.jp changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtasaka at ioa.s.u-tokyo.ac.jp




------- Additional Comments From mtasaka at ioa.s.u-tokyo.ac.jp  2007-11-10 09:39 EST -------
Well,

* About dangling-relative-symlink:
  - Well, this "dangling-relative-symlink" warnings themselves 
    can be ignored when you check "installed" rpms by rpmlint like
    $ rpmlint httrack httrack-devel.

    However, for this package some points need considering.
    Actually why do the symlinks under %_libdir/httrack needed for
    -devel package? The "real" binaries which these symlinks point to
    are not under ldconfig search path so no external libraries or
    binaries can be linked against these binaries.
    For me the files under %_libdir/httrack are modules loaded
    by httrack binaries only and all symlinks under %_libdir/httrack
    and included in -devel package are not needed.

* openssl header used?
  - From %_includedir/httrack/htsbasenet.h
-----------------------------------------------------
    77  /*
    78  #include <openssl/ssl.h>
    79  #include <openssl/crypto.h>
    80  #include <openssl/err.h>
    81  */
-----------------------------------------------------
    All in comments!!

By the way..
* undefined-non-weak-symbol
  - $ rpmlint httrack shows
-----------------------------------------------------
httrack.i386: W: undefined-non-weak-symbol /usr/lib/libhtsjava.so.2.0.41 hts_malloc
httrack.i386: W: undefined-non-weak-symbol /usr/lib/libhtsjava.so.2.0.41 get_ext
httrack.i386: W: undefined-non-weak-symbol /usr/lib/libhtsjava.so.2.0.41 fconv
httrack.i386: W: undefined-non-weak-symbol /usr/lib/libhtsjava.so.2.0.41
get_httptype
httrack.i386: W: undefined-non-weak-symbol /usr/lib/libhtsjava.so.2.0.41 is_dyntype
-----------------------------------------------------
    And there is a symlink "libhtsjava.so" which points to 
    libhtsjava.so.2.0.41
    - If libhtsjava.so is supposed to be able to be linked from external
      libraries/binaries, then these undefined non-weak symbols should
      be fixed because these symbols canse linkage failure.
      It seems all these symbols are provided from libhttrack.so, so
      making htsjava.so link against libhttrack.so should fix this issue.

* generic header file name and generic macro name in
  header file.
  - Header files with generic header names like "config.h" and
    generic macros like HAVE_STDLIB_H or so is very troublesome.
    Please see the explanation by Hans in
    https://bugzilla.redhat.com/show_bug.cgi?id=232342
    or
    https://bugzilla.redhat.com/show_bug.cgi?id=208034#c43
    and
    - Remove config.h or at lease rename config.h
    - config.h is used in htsglobal.h and some generic macro names
      are used. Modify the macro names to avoid name space conflict.

* Dependency for firefox or so
  - %{_bindir}/webhttrack seems to require some browser so
    this package should require some browser.
    - If possible, change the script so that webhttrack uses
      xdg-open first and make this package require "xdg-utils".

* File entry
  - By the way, the file entries
-----------------------------------------------------------------
%files
%dir %{_datadir}/%{name}
%{_datadir}/%{name}/*
-----------------------------------------------------------------
    can be replaced by
-----------------------------------------------------------------
%files
%{_datadir}/%{name}/
-----------------------------------------------------------------


-- 
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, or are watching someone who is.




More information about the Fedora-package-review mailing list