On Wed, Jun 22, 2005 at 11:04:58PM +0100, Phil Endecott wrote: > 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. > It would be best to introduce some form of version management. Binary incompatibilities should be a minor issue at worst. > 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. > It is definitely better to deal with versioning problems. Including a custom version of ROTE with anyterm would probably cause the package to be rejected. As it currently stands, the packages in Debian are being swept to eliminate cases of packages including their own library code that exists in external libraries. There are ways that this can be justified, but it is better to get the library to handle this correctly. > 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. > Have you considered forking ROTE or asking Bruno to allow you to take a more active role (like CVS commit access)? > > 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. > My intent is the following: * apt-get install gets the files in place, but the module remains disabled * Document well all potential security issues and provide references for external reading (including the anyterm web pages/forums). > 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. > I look forward to that. However, until the issue with the roteprivate.h header is resolved, I am going to put this on hold. As I said in my last mail, the librote packages are ready. I will continue to update them as necessary, and you can feel free to use them and give me feedback (e.g., are they functionally identical to the from-source version you are using). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr
Attachment:
pgph_2NOmgOFm.pgp
Description: PGP signature