rTorrent: a ncurses torrent client bound to one libtorrent version

The build stalls on a libtorrent version mismatch

The dependency section is three lines and one of them is a constraint rather than a minimum: libcurl >= 7.12.0, ncurses, and libtorrent at the same version. The build section says the same thing in prose, that rTorrent follows the development of libtorrent closely and therefore the versions must be in sync, and it tells you to install libtorrent with the same version as rTorrent before doing anything else. The build side needs the autotools pieces: libtoolize, aclocal, autoconf, autoheader, and automake. That pairing rule is the practical constraint for anyone packaging rTorrent, because you are shipping two libraries whose versions move together, and a distribution that holds libtorrent at the version its archive prefers will fail this build rather than degrade.

autoreconf is the only build path the README prints

The build instructions are two commands.

cd rtorrent
autoreconf -ivf

autoreconf generates the configure scripts, which tells you what kind of project this is. The root of the repository is an autotools tree: configure.ac and Makefile.am sit beside INSTALL, AUTHORS, COPYING, and the source lives under src/ with doc/, lua/, scripts/, and test/ directories around it. No cmake, meson, or plain makefile route appears anywhere in the README, so a distribution package that wants to avoid running autoreconf during the build has no path the project documents. There is also a .clang-format and a .clang-tidy at the root, which is what you would expect from a C++ project that expects its own formatting to be applied.

Man pages need docbook2man, which no dependency list names

Man pages are optional and the command is given separately.

docbook2man rtorrent.1.xml

The output lands in doc/rtorrent.1, and doc/ is one of the directories in the repository. The gap is in the dependency lists: neither DEPENDENCIES, which holds libcurl, libtorrent, and ncurses, nor BUILD DEPENDENCIES, which holds libtoolize, aclocal, autoconf, autoheader, and automake, mentions docbook2man. So on a build host with only the listed packages installed, that optional step fails, and the README does not name the distribution package that provides the tool. Worth knowing before a packaging script treats the man page step as part of a standard build.

Usage questions are answered in the wiki, not the repository

Every runtime question is delegated. The introduction sends you to the wiki to learn how to use rTorrent, and the usage section points at a User Guide page inside that wiki. The README itself prints no runtime commands, no configuration file path, no key bindings, and no description of what the interface looks like beyond calling it ncurses-based and aimed at high performance. The practical consequence is that the common questions about this client, how to quit it, where its rc file lives, which commands exist, cannot be answered from the repository at all. If you are writing documentation or a wrapper script, the wiki is the only source the project points to, and anything not in that wiki is not documented anywhere the project sends you.

rbedit is the only related project, and it edits bencode

The Related Projects section names exactly one project: rakshasa/rbedit, described as a dependency-free bencode editor. That is a small but pointed choice. A torrent file is bencode, and a tool with no dependencies is what you want on a machine where installing a library is not an option, for instance when a .torrent file is malformed and the client that produced it will not load it. The README names no web interface, no alternative client, and no plugin system, so anyone arriving from search results expecting a browser based front end will not find one listed here. The only other links in the file are the download link for the latest stable release and the donation channels.

One file carries a triple licence and an OpenSSL exception

The licence section is more interesting than a single licence line. The project is GNU GPL, with the text in COPYING, but libtorrent/src/utils/sha_fast.cc and its header came from Mozilla NSS and are under MPL, LGPL, and GPL together. An exception was added for non-NSS code so it can link against OpenSSL, at Debian's request, although the author argues that OpenSSL is part of the operating system and therefore linking is allowed under the GPL anyway. The escape hatch is preserved: the code needed to compile against Mozilla's NSS implementation of SHA1 was kept, so a build that wants to avoid OpenSSL can use it instead. If your distribution audits licences per file rather than per project, that one path is the item to review.

0.16.25 shipped on the same day as the last commit

The release rhythm is fast and visible in the tags. v0.16.27 was published on 2026-10-28, v0.16.26 on 2026-10-22, and v0.16.25 on 2026-10-05, and the last push to the default branch master is dated 2026-10-31. That pairing matters for the version rule in the build section: when a new tag appears, the matching libtorrent release is what you need, not whatever version your distribution already ships. The repository is not archived, the licence is GPL-2.0, the primary language is C++, and the wiki is the project's declared home page.

Editorial conclusion

Use rTorrent if you want a torrent client that lives in a terminal and that you can script, and if you are prepared to package libtorrent alongside it at the same version. Do not pick it expecting a self-contained installer, since the build starts with autoreconf and the runtime instructions live in a wiki rather than in the repository. Before you start, install the matching libtorrent first, keep a copy of the exact version numbers you pair, and read the licence note about the SHA-1 code if your distribution has opinions about OpenSSL and Mozilla NSS.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. rakshasa/rtorrent on GitHub
4. README
5. Releases