Roberto C. Sanchez wrote:
# From version 0.11, Anyerm needs to access data in an internal # ROTE data structure. To do so it needs to find the roteprivate.h # header file, which is in the rote source directory. Please adjust # the following line to specify the directory in which this file can # be found. ROTE_PRIVATE_DIR=/usr/local/src/rote There are only two ways to solve this for the packaging of anyterm as a Debian package: 1. Copy the roteprivate.h file from librote-dev into the source package for anyterm. 2. Put the roteprivate.h into the librote-dev package. Neither is acceptable. The only alternative I can come up with is to talk to Bruno (the ROTE) developer and see if he is willing to include the data structures that you need directly in the rote.h header.
Anyterm reads the file descriptor for the pseudoterminal that ROTE creates (backend.cc, lines 107 & 294). This is currently in the private part of the ROTE state. It could easily be moved to the public part of the state, but it would result in binary incompatibilities: programs using ROTE would have to be recompiled. Currently there is no attempt at library version management. I do not know the best way to cope with this, so there is the current hack.
At some point in the future I may need other binary-incompatible changes to ROTE. One example is support for UTF-8. Another is support for "not-pseudo" terminals, e.g. serial ports, another is underlining. When I come to this I will consider whether it is better to get these changes back into ROTE and deal with the library verioning problem, or include a modified version of ROTE with the Anyterm source.
In the past Bruno has accepted my patches and included them in the project's CVS repository, but they have never made it into a release. My feeling is that Bruno finds the current ROTE to be quite adequate for his purposes, and while he is pleased to see it being used, he does not have much time for working on it.
How you proceed is entirely up to you.A far more important consideration is how you intend to package this in a secure fashion, so that users (a) know what they are installing, and (b) are presented with a quick-and-easy way to make it as secure as it can be. "apt-get install" skips all the security warnings that someone installing from the online instructions would see. For example, someone has today posted a good solution to the problem of Apache log files using SetEnvIf. You certainly ought to include something like that.
A couple of issues have been found in 1.1.2. There will probably be a 1.1.3 in the next couple of days.
Regards, --Phil.