[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Please allow libtorrent-rasterbar 0.13.1-2 propagate to lenny



Hi all,

I noticed that libraries are already frozen, but I'd like to ask an exception
for libtorrent-rasterbar: could you allow revision 0.13.1-2 to reach testing
before freeze? It would be really important to have this version in stable
release, for the following reason.

I was building new qbittorrent version 1.1.0rc1 (which is actually the only
r-depends of libtorrent-rasterbar in Debian - deluge-torrent still uses an old
shipped version of the library) when I noticed that there are, in effect,
problems with libtorrent-rasterbar built with --enable-debug option (as of
revision 0.13.1-1). At the time of library first upload, upstream told me that
enabling debug was not a problem for clients... but in reality it is. In fact:

- qbittorrent can handle both debug and release versions of libtorrent, but it
  must be built with a specific option: this 1.1.0rc1 has debug option disabled
  by default (it was enabled in previous 1.1.0beta3), so it would crash with
  libtorrent-rasterbar 0.13.1-1;
- btg crashes if libtorrent is built with debug enabled [1] and upstream
  author told me he would prefer a release build;
- deluge-torrent still uses a shipped version of libtorrent and (although
  upstream author is not actually interested in using a system version of the
  library) it builds libtorrent-rasterbar with debug disabled.

As now, libtorrent-rasterbar 0.13.1-2 builds a release version (debug disabled)
and qbittorrent 1.1.0~rc1 strictly build-depends on this last revision.

So, there are two reasons for allowing libtorrent-rasterbar 0.13.1-2 go into
lenny:

- new qbittorrent version 1.1.0~rc1 (which closes a RC bug and a FTBFS)
  build-depends on libtorrent-rasterbar 0.13.1-2;
- it is a nonsense to release libtorrent-rasterbar to stable in a probably
  unusable state: qbittorrent is actually the only r-depends, but there are
  many packages using libtorrent-rasterbar and all upstream authors seem to
  agree to use a release version of the library. I guess it could be a problem
  for a stable release.


Thanks,
Cristian

[1] http://btg.berlios.de/faq.html#libtorrent-asserts

Attachment: signature.asc
Description: Digital signature


Reply to: