From the official website: "CTorrent Control Server (CTCS) is an interface for monitoring and managing Enhanced CTorrent clients. It can manage allocation of bandwidth, provide status information, and allow changes to the running configuration of each client. Communication with CTorrent is via a TCP connection, and the user interface is a web browser." License is as-is, as per the script header. As you'll see, the ebuild is pretty simple, it just installs a Perl script and a readme file. It depends on ctorrent with latest -dnh patchset, as in bug #131903. Note that there is already an unrelated app-admin/ctcs package in the tree. I've checked they had no file collisions for now. I can rename this ebuild if you think it's safer though (since collision may happen in the future, for instance in /usr/share/doc if both get versioned the same).
Created attachment 85934 [details] ctcs-1.0a.ebuild
Will the "enhanced" ctorrent client be merged with upstream ctorrent in the future, or is it a separate project? If it's a separate project and upstream ctorrent will never have the tcp connection of enhanced ctorrent, we need to have two different ctorrent packages in portage, and have this package depend on the newer package.
From what i've seen, -dnh has been the only lively branch for a long time, and there is no other CTorrent which would have the bugfixes but not the enhancement (including the TCP control protocol now). But i really don't know more, and don't have a clue of what may happen in the future. But, imho it's not really a problem atm though: if there is ever an official ctorrent-1.3.5 (or whatever) which doesn't include this control protocol, then it will still be time to create a separate package for the enhanced branch, and to change the dep in ctcs. No?
That sounds reasonable to me. I'll go ahead and take a look through this package and let you know if we can add it to portage (either tonight or tomorrow night, depending on how much time I had).
In the tree, thanks.
