Bug 366121

One of the headers installed by httrack-devel includes the openssl-devel headers.

./src/htsbasenet.h:78:#include <openssl/ssl.h>
./src/htsbasenet.h:79:#include <openssl/crypto.h>
./src/htsbasenet.h:80:#include <openssl/err.h>

However there does not seem to be any need for BuildRequires: openssl-devel. Is
this alright? Why install headers which include stuff which are not even needed
for building the library?

[rishi@ginger i386]$ rpmlint httrack-devel-3.41.3-1.fc8.i386.rpm 
httrack-devel.i386: W: dangling-relative-symlink /usr/lib/httrack/liblog.so
liblog.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink /usr/lib/httrack/libfilename.so
libfilename.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libcontentfilter.so libcontentfilter.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libfilenameiisbug.so libfilenameiisbug.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libchangecontent.so libchangecontent.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/liblistlinks.so liblistlinks.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libdisplayheader.so libdisplayheader.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libfilename2.so libfilename2.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink /usr/lib/httrack/libsimple.so
libsimple.so.1.0.0
httrack-devel.i386: W: dangling-relative-symlink
/usr/lib/httrack/libbaselinks.so libbaselinks.so.1.0.0
httrack-devel.i386: E: only-non-binary-in-usr-lib
[rishi@ginger i386]$ 

Running 'nm' on the installed *.so* files from the RPM does not return any
symbols. However if they are installed from the tarball (./configure
--disable-static --prefix=/usr && make && make install DESTDIR=/opt) then 'nm'
displays the symbols.

Also I can not understand the "dangling-relative-symlink" warning. All the *.so
files in the -devel, when installed are properly linked to their corresponding
*.so.* counterparts.

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=225943

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}/
-----------------------------------------------------------------

(In reply to comment #3)
> * About dangling-relative-symlink:

Fixed. I have contacted upstream for confirmation. Looking at the Makefiles, I
gather that the libraries under /usr/lib/httrack were created from the libtest/
files, which are appear to mere examples.

> * openssl header used?
>
> [...]
>
>     All in comments!!

Silly me!

However we do need a 'Requires: openssl' for the main package because
src/htsmodules.c tries to dlopen libssl.so*.
 
> By the way..
> * undefined-non-weak-symbol
 
Not yet fixed. I am looking into this.

> * generic header file name and generic macro name in
>   header file.

Not yet fixed.

Many of the macros are used to differentiate between #ifdef _WIN32 and so on.
Clearly we would not have _WIN32 defined in Fedora -- Fedora is GNU/Linux and
not Windows. So can I just remove all those _WIN32 (and similar) specific
portions from htsglobal.h ?

> * Dependency for firefox or so

Fixed.

> * File entry
>   - By the way, the file entries
>
> [...]
>
>     can be replaced by

I have used this style in all my specs, since I like to differentiate between
directories and files. Maybe this sounds silly, but I hope you will allow it. :-)

Spec: http://rishi.fedorapeople.org/httrack.spec
SRPM: http://rishi.fedorapeople.org/httrack-3.41.3-2.fc8.src.rpm

Well, I have not checked your -2 srpm, however:

(In reply to comment #4)
>> * generic header file name and generic macro name in
>>   header file.
> Not yet fixed.
> 
> Many of the macros are used to differentiate between #ifdef _WIN32 and so on.
> Clearly we would not have _WIN32 defined in Fedora -- Fedora is GNU/Linux and
> not Windows. So can I just remove all those _WIN32 (and similar) specific
> portions from htsglobal.h ?

Well, the most problematic file is config.h
- At first, the name "config.h" is too generic.
- And this file contains many generic macros.

So A
- At first config.h must be removed.
- Then as htsglobal.h contains some generic macros
  defined in config.h like
--------------------------------------------------------
   124  #else
   125  
   126  #include "config.h"
   127  
   128  #ifndef FTIME
   129  #define HTS_DO_NOT_USE_FTIME
   130  #endif
   131  
   132  #ifndef SETUID
   133  #define HTS_DO_NOT_USE_UID
   134  #endif
   135  
-----------------------------------------------------
  Please rename FTIME and SETUID and define/undefine HTS_FTIME
  (for example) in some places, for example
  (by the way, are these lines really needed?)


> 
> > * Dependency for firefox or so
> 
> Fixed.
> 
> > * File entry
> >   - By the way, the file entries
> >
> > [...]
> >
> >     can be replaced by
> 
> I have used this style in all my specs, since I like to differentiate between
> directories and files. Maybe this sounds silly, but I hope you will allow it. :-)
> 
> Spec: http://rishi.fedorapeople.org/httrack.spec
> SRPM: http://rishi.fedorapeople.org/httrack-3.41.3-2.fc8.src.rpm

Spec: http://rishi.fedorapeople.org/httrack.spec
SRPM: http://rishi.fedorapeople.org/httrack-3.42-1.fc8.src.rpm

I have tried to fix the generic headers and macros issue. Most of those macros
were used to differentiate Win32 based systems from UNIX based ones, so I have
simply removed them.

Now it seems okay for namespace conflicts of header files
and macros in header files.

For 3.42-1:
* Version
  - Maybe it is better that rpm version of current httrack
    is set as 3.42.1.

* openssl dependency
  - Maybe it is better that openssl dependency is version
    specific, i.e. "Requries: openssl = 0.9.8b" ?

* undefined-non-weak-symbol
  - Now please fix undefined non-weak symbols on libhtsjava.so.2.
    Making this library linked against libhttrack.so should
    fix this problem (I guess).

* Documents
  - Maybe "history.txt" can be added to %doc?

(In reply to comment #7)
 
> For 3.42-1:
> * Version
>   - Maybe it is better that rpm version of current httrack
>     is set as 3.42.1.

The latest version is 3.42. Even though the tarball contains a 3.42.1 directory,
we can not trust this, since in the past we have had 3.41 ->  3.41-2 -> 3.41-3
-> 3.42 and the directory inside the tarball has not always been similar to the
release numbers. So I just want to ignore the directory name and use the version
number mentioned on the site and history.txt after replacing the '-' (if any)
with a '.'.

I will try to contact upstream to resolve this confusion for the future.

(In reply to comment #7)

> * openssl dependency

The minimum NEVRA of openssl in Fedora is openssl-0.9.8b-12.fc7. So the version
should not be needed in the Requires.
 
> * undefined-non-weak-symbol

Fixed.

> * Documents

It was already there as html/history.txt, but I have put it outside since the
links from html/index.html do not work correctly otherwise.

Spec: http://rishi.fedorapeople.org/httrack.spec
SRPM: http://rishi.fedorapeople.org/httrack-3.42-2.fc8.src.rpm
Koji: http://rishi.fedorapeople.org/httrack-3.42-2.fc8.src.rpm

(In reply to comment #9)
> (In reply to comment #7)
> > * openssl dependency
> 
> The minimum NEVRA of openssl in Fedora is openssl-0.9.8b-12.fc7. So the version
> should not be needed in the Requires.

I am thinking of the case when Fedora openssl is upgraded.
In that case adding "Requires: openssl = 0.9.8b" tells us that
httrack must be rebuilt (more properly, the patch applied must
be updated), like firefox upgrade.

Spec: http://rishi.fedorapeople.org/httrack.spec
SRPM: http://rishi.fedorapeople.org/httrack-3.42-3.fc8.src.rpm

Fixed.

Okay.

--------------------------------------------------
   This package (httrack) is APPROVED by me
--------------------------------------------------

New Package CVS Request
=======================
Package Name: httrack
Short Description: Website copier and offline browser
Owners: rishi
Branches: F-7 F-8
InitialCC: 
Cvsextras Commits: no

cvs done.

Package Change Request
======================
Package Name: httrack
New Branches: el6 epel7
Owners: cicku

Git done (by process-git-requests).

httrack-3.47.27-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/httrack-3.47.27-1.el6

httrack-3.47.27-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.