Jan> SL Baur <steve(a)beopen.com&gt; writes: That's OK for our sample binary kits, but there is no way that you are going to get 3rd party distributors to comply. And there's no reason that they should, if they take responsibility for supporting their kits. Complaints about binaries provided by a Linux distribution should simply be referred to the distribution's bug-list. If the maintainer is too lazy to deal with it, Martin or Ben writes them a "lawyer letter" and we put them in our "Unsupported Platforms" list. ;-) Then we try to help the poor user. In particular, we could cons up a "report-distributor-bug" function and put it in the help menu, probably substituting it for the current "report-emacs-bug" function. ./configure gets an option "--maintainer-address=". And the bug-report function requires user intervention to get addressed to xemacs.org. Something like: You are submitting a bug report on XEmacs foo.bar.baz. If the "To:" address is not filled in and you are using a binary distributed by a third party, it is best to find out the address of the third party maintainer and report to them first. XEmacs provides many very flexible configuration options, and many apparent bugs are actually configuration errors, such as configuring for the build machine's environment and installing on a different machine. Obviously XEmacs.org cannot control or fix the configuration or installation decisions of third parties. Since the downstream maintainer did not see fit to configure their own address for bug reports, we suggest you consider whether they are reliable enough for your purposes, or whether you need a new distributor. In the meantime, please hand-address your mail to XEmacs Bugs <xemacs-bug(a)xemacs.org&gt;, and customize the variable `maintainer-address' appropriately. If you build your own XEmacs, you should use the "--maintainer-address=" option to configure. We recommend that you join the developer's mailing list and send bug reports there; see http://www.xemacs.org. Otherwise you can send them to XEmacs Bugs <xemacs-bug(a)xemacs.org&gt;. could either be inserted in the message text or popped up as a help window and query for the address, and optionally customize. (It just occurred to me that maybe we should put a sort of time limit on the customization by including version information in the variable name.) Maybe that's too pushy? OTOH, Debian generally has a policy of providing such addresses (I think that one of their customizations of XEmacs is very much along to above lines), and most distributions would prefer to avoid friction with upstream developers. And this particular kind of complaint about dependencies should get a canned response: "It's a FAQ: Q#.#.###." If it's not in our FAQ, it should be. (I'll follow this up, myself.) Jan> Yes, but on many platforms static linking is a no-no anyway. Jan> Especially binaries for linux distributions (that can control Jan> the versions of all the libraries) should not be statically Jan> linked. Bull. There are all sorts of good reasons for static linking, even on Linux. For example, due to Adobe brain-deadness (sm), the standard libjpeg is incompatible with Adobe Postscript (tm) usage. So Ghostscript by default statically links a modified version of libjpeg, with the Adobe brain-deadness built in. (Most Linux distributors ignore this for some reason. Sigh.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."