Bug 221372 - (rb_libtorrent) Review Request: rb_libtorrent - A C++ BitTorrent library aiming to be the best alternative
Review Request: rb_libtorrent - A C++ BitTorrent library aiming to be the bes...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT python-libtorrent
  Show dependency treegraph
 
Reported: 2007-01-03 23:49 EST by Peter Gordon
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-28 14:43:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Gordon 2007-01-03 23:49:51 EST
Spec URL: http://www.thecodergeek.com/downloads/fedora/rb_libtorrent.spec
SRPM URL: http://www.thecodergeek.com/downloads/fedora/rb_libtorrent-0.11-1.src.rpm
Description: This is a C++ library that aims to be a good alternative to all
the other BitTorrent implementations around. It is a library and not a full
featured client, although it comes with a working example client.

Its main goals are to be very efficient (in terms of CPU and memory usage) as
well as being very easy to use both as a user and developer.


A quick comment on the naming: There is already a separate libtorrent package in Extras, but this is a different project entirely, and I must use a separate name from the one already in Extras. I looked into it a bit more deeply, and other distributions such as Gentoo and Arch us "rb_libtorrent"; hence I chose the same name to follow suit and keep consistent with them.


This is being packaged as an indirect dependency for the Deluge BitTorrent client.
Comment 1 Peter Gordon 2007-01-03 23:50:50 EST
[ Adding David to the CC list at his request. ]
Comment 2 Peter Gordon 2007-01-06 03:03:43 EST
Additionally, the -devel subpackage installs a .pc file, so it should require
pkgconfig. I've added that in release 2.

The .spec file is at the same URL; and the source RPM is at
http://www.thecodergeek.com/downloads/fedora/rb_libtorrent-0.11-2.src.rpm

Thanks.
Comment 3 Michael Schwendt 2007-01-17 11:43:35 EST
Re-check "License:" as it is _not_ GPL.

> ## Uses the same naming schema for libraries/directories :( 
> Conflicts:	libtorrent

IMO this conflict is unacceptable. Actually, "libtorrent" is
libtorrent.so.9, this one is libtorrent.so.0, and "libtorrent-devel"
uses /usr/include/torrent/ while this one uses /usr/include/libtorrent/.
So, theoretically they could even co-exist at this point of time,
provided that they got some love from upstream. But so far, the
rename is half-hearted.

> %files
> %{_bindir}/client_test
> %{_bindir}/simple_client

For a library package and the limited /usr/bin namespace, these two
file names are far too generic. They ought to be moved or renamed.

The filenames /usr/bin/dump_torrent and /usr/bin/make_torrent are
quite generic, too. Upstream is highly encouraged to choose an own
namespace.

> %files devel
> %doc COPYING docs/*

The file COPYING is included in the main package already.

> %{_libdir}/pkgconfig/libtorrent.pc

This file is tuned for static linking, unfortunately, in that
it links libraries which libtorrent.so.0 is linked against
already.

> Requires: openssl-devel

Where do you see this requirement?
Comment 4 Peter Gordon 2007-01-17 15:37:43 EST
> Re-check "License:" as it is _not_ GPL.
Gaah. I just copied that from the Gentoo ebuild without verifying it. Thanks for
the catch.

> IMO this conflict is unacceptable. Actually, "libtorrent" is
> libtorrent.so.9, this one is libtorrent.so.0, and "libtorrent-devel"
> uses /usr/include/torrent/ while this one uses /usr/include/libtorrent/.
> So, theoretically they could even co-exist at this point of time,
> provided that they got some love from upstream. But so far, the
> rename is half-hearted.
On further investigation, only some of the -devel files conflict (libtorrent.pc
and the unsuffixed libtorrent.so symlink). I'll make only the -devel subpackage
conflict with that of libtorrent, then.

> For a library package and the limited /usr/bin namespace, these two
> file names are far too generic. They ought to be moved or renamed.
Well, these binaries are actually just examples of what can be done with
this libtorrent. Would they be better suited as %doc perhaps?

> The file COPYING is included in the main package already.
Perhaps; but as a matter of personal preference and to keep things explicitly
clear, I prefer to package such files as %doc for every subpackage in a build.

> This file is tuned for static linking, unfortunately, in that
> it links libraries which libtorrent.so.0 is linked against
> already.

Hmm. I was under the [apparently mistaken] impression that forcing the use of
the system zlib would offset that from the ./configure script. A patch is underway.

>> Requires: openssl-devel
> Where do you see this requirement?

Several OpenSSL headers are used via #include directives from files in the
/include/libtorrent/asio/ssl directory (used for asynchronous SSL handshaking
and whatnot). Thus, I have it pull in openssl-devel so that any potential build
finds those headers as well.

When I home this evening, I'll bug upstream about the dump_torrent/make_torrent
naming, as well as fix the issues presented in your comment.

Thanks.
Comment 5 Peter Gordon 2007-01-18 00:28:07 EST
(In reply to comment #4)
> > This file is tuned for static linking, unfortunately, in that
> > it links libraries which libtorrent.so.0 is linked against
> > already.
> 
> Hmm. I was under the [apparently mistaken] impression that forcing the use of
> the system zlib would offset that from the ./configure script. A patch is
underway.

Actually, it properly uses "-lz" in the libtorrent.pc file when built and
installed in the buildroot; so such a patch is unneeded. It's just the
as-shipped libtorrent.pc that contains the zlib.la usage.

$ grep Libs /usr/lib/pkgconfig/libtorrent.pc 
Libs: -L${libdir} -lz  -lboost_date_time -lboost_filesystem -lboost_thread -lz
-ltorrent

$ rpm -qf /usr/lib/pkgconfig/libtorrent.pc 
rb_libtorrent-devel-0.11-3.i386

For the file naming stuff, I renamed everything to include "torrent"; and have
sent a message to the upstream development list with regards to this.

Other stated issues are fixed in release 3.

Spec: http://thecodergeek.com/downloads/fedora/rb_libtorrent.spec
SRPM: http://thecodergeek.com/downloads/fedora/rb_libtorrent-0.11-3.src.rpm

Thanks.
Comment 6 Michael Schwendt 2007-01-18 08:03:47 EST
> /include/libtorrent/asio/ssl

Ah, yes.


> $ grep Libs /usr/lib/pkgconfig/libtorrent.pc 
> Libs: -L${libdir} -lz  -lboost_date_time -lboost_filesystem
> -lboost_thread -lz -ltorrent

should read:

$ grep Libs /usr/lib/pkgconfig/libtorrent.pc 
Libs: -L${libdir} -ltorrent

Because libtorrent is linked against zlib and boost already,
see:   ldd /usr/lib/libtorrent.so.0

Not a big issue, though. The pkgconfig file should tell what is
necessary to compile with and link with libtorrent, not tell what
libtorrent was built with. This is a mistake done by several
upstream projects. They squeeze everything, which was used for
building libtorrent, into the "Libs" line. The full set of -lfoo
options is only needed for static linking (or special forms of
linking).
Comment 7 Mamoru TASAKA 2007-01-26 02:12:17 EST
Then first try this...
Comment 8 Mamoru TASAKA 2007-01-26 04:48:51 EST
Before checking this..

Can't the conflict between libtorrent <-> this package be
avoided simply by moving
* /usr/lib/libtorrent.so -> /usr/lib/librb_torrent.so
* /usr/lib/pkgconfig/libtorrent.pc -> /usr/lib/pkgconfig/librb_torrent.pc
?

I don't want to make use of "conflict" simply because the
file entry duplicates when some seemingly-easy solution exists,
because this type of file conflicts always occur on making
compat version rpm.

Would you consider to aviod using conflict by renaming?
I also suggest when you agree, the "real" dynamic library
"/usr/lib/libtorrent.so.0.1.0" and the header directory
"/usr/include/libtorrent" should be renamed as such.
Comment 9 Peter Gordon 2007-01-26 16:26:22 EST
(In reply to comment #8)
> Can't the conflict between libtorrent <-> this package be
> avoided simply by moving
> * /usr/lib/libtorrent.so -> /usr/lib/librb_torrent.so
> * /usr/lib/pkgconfig/libtorrent.pc -> /usr/lib/pkgconfig/librb_torrent.pc
> [...]
> ?

Unfortunately, it is not necessarily that simple, as this would require all
packages building against it to be reconfigured to use the 'rb_libtorrent'
naming (patching the necessary build scripts), whereas other distributions
maintain the simple conflict and note that it is different from the Rakshasa
library of the same name. One of my ideals is to, within reason, keep the
packaging of a piece of software very similar between distributions; and having
to maintain a Fedora-specific patching to it (as well as anything that would
potentially build/link against it, such as python-libtorrent) would give us
harm us in terms of this packaging difference more than the no-Conflicts help
it would bring us.

Thanks.
Comment 10 Mamoru TASAKA 2007-01-27 12:26:43 EST
Well, for 0.11-3:

* License:
  - Well, some sources are not licensed under BSD.

  A. Some files are under the Boost Software License
     (perhaps okay)
     [under include/libtorrent/]:
     asio.hpp asio/*.hpp asio/*/*.hpp
     invariant_check.cpp

  B. Need some verification
     [under include/libtorrent/]
     utf8.hpp
------------------------------------------------------
1. The origin of this software must not be misrepresented; you must not
   claim that you wrote the original software. If you use this software
   in a product, an acknowledgment in the product documentation would be
   appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
   misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
-------------------------------------------------------

* Fedora specific documentation
  - Please include your name.

* Timestamps
  - This package try to install many text files/image files
    and in that case keeping on those files are preferable.
    For this package please:
--------------------------------------------------------
%install
rm -rf %{buildroot}
export CPPROG="%{__cp} -p"
make install DESTDIR=%{buildroot} INSTALL="%{__install} -c -p"
--------------------------------------------------------

* Requires, etc
  /usr/lib/pkgconfig/libtorrent.pc includes:
--------------------------------------------------------
Libs: -L${libdir} -lz  -lboost_date_time -lboost_filesystem -lboost_thread -lz
-ltorrent
--------------------------------------------------------
  * I doubt that addtional linkage is needed as 

Comment 11 Mamoru TASAKA 2007-01-27 12:48:58 EST
(In reply to comment #10)
>   B. Need some verification
>      [under include/libtorrent/]
>      utf8.hpp
Okay, this is zlib, free and GPL-compatible.
So, this is licensed under 3 kinds of license,
BSD, Boost and zlib.
Comment 12 Peter Gordon 2007-01-27 17:58:34 EST
I've noted the separate licenses; but AFAICT they all are very similar to the
BSD license (mostly "do what you want with the code, so long as the original
authors' copyrights are left intact and the license text is not altered")
 
> * Fedora specific documentation
>   - Please include your name.
Fixed in release 4.

> * Timestamps
>   - This package try to install many text files/image files
>     and in that case keeping on those files are preferable.
>     For this package please:
> --------------------------------------------------------
Fixed in release 4.

> * Requires, etc
>   /usr/lib/pkgconfig/libtorrent.pc includes:
> --------------------------------------------------------
> Libs: -L${libdir} -lz  -lboost_date_time -lboost_filesystem -lboost_thread -lz
> -ltorrent
> --------------------------------------------------------
>   * I doubt that addtional linkage is needed as 
Ah I see. Since we're linking against the system zlib, both the the @ZLIB@ and
@LIBS@ macros in the input file are expanded to contain '-lz' in the final
libtorrent.pc file. I've fixed this in release 4.

Spec: http:/thecodergeek.com/downloads/fedora/rb_libtorrent.spec
SRPM: http:/thecodergeek.com/downloads/fedora/rb_libtorrent-0.11-4.src.rpm

Thanks for your time and comments!
Comment 13 Mamoru TASAKA 2007-01-28 10:18:02 EST
Okay.
-----------------------------------------------------
  This package (rb_libtorrent) is APPROVED by me.
Comment 14 Michael Schwendt 2007-01-28 12:31:08 EST
Bottom of comment 6 still holds true, doesn't it?
Comment 15 Mamoru TASAKA 2007-01-28 12:48:35 EST
(In reply to comment #14)
> Bottom of comment 6 still holds true, doesn't it?

I allowed it because Peter seemed to have some reasons,
however generally the extra linkage you pointed out
should be removed.

However, I will not get FE-ACCEPT flag back for this
reason now.
Comment 16 Michael Schwendt 2007-01-28 12:55:32 EST
> because Peter seemed to have some reasons,

Not documented in this ticket. What are those reasons?
Comment 17 Peter Gordon 2007-01-28 13:00:52 EST
Ack. I already imported it and submitted it to the build system for devel (job
26582). >_>

I will fix this in CVS and submit a new build. Thanks; and sorry for the slight
misunderstanding!
Comment 18 Peter Gordon 2007-01-28 14:23:20 EST
(In reply to comment #17)
> Ack. I already imported it and submitted it to the build system for devel (job
> 26582). >_>
> 
> I will fix this in CVS and submit a new build. Thanks; and sorry for the slight
> misunderstanding!

Fixed in 0.11-5 (job 26587). Thanks!!

Note You need to log in before you can comment on or make changes to this bug.