Jerry James <james(a)xemacs.org&gt; writes: Given that version 11.55 is 1.5 years old and the next version after it almost a year, it seems appropriate not to talk about "New Features" here. I don't know your rationale for not using the "rawfile" toggle when generating raw files instead of info files, but the upstream distribution clearly generates those files with this option set in order to avoid info-like cross references, replacing them with explicit descriptions where appropriate. If you choose a nonstandard setup for generating those files, leading to different content than that of the main distribution, I find the claim that the completed XEmacs package from the XEmacs CVS tree fully satisfies the GPL condition 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, [Options b) and c) are not taken and elided here] The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used ^^^^^^^^^^^^^^^^^^^^^ to control compilation and installation of the executable. ^^^^^^^^^^^^^^^^^^^^^^ I don't really think it an appropriate idea to distribute a set of files compiled with different than the standard settings without also distributing the responsible scripts and settings. Since you presumably start with AUCTeX from its distribution tarball, is there anything wrong in just checking in the requisite precompiled files in the same form as they are already in the tarball? That way, no options or scripts of yourself are involved and would warrant distribution, and your files don't differ from those of upstream. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

David> I don't really think it an appropriate idea to distribute a David> set of files compiled with different than the standard David> settings without also distributing the responsible scripts David> and settings. We do distribute everything, just not as part of the prebuilt AUCTeX package. If it is not possible to check out the package tree from CVS and rebuild the package, that is a bug and we will fix it. David> is there anything wrong in just checking in the requisite David> precompiled files in the same form as they are already in David> the tarball? As a solution to the current issue, yes, there is. That means our users can't build modified versions using our framework, and that's not acceptable to us. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I think you misunderstand me here, and perhaps my wording has not been chosen well. I meant It would probably make sense to take a look at it and model the procedure how the XEmacs team chooses to organize the CVS packaging of AUCTeX from there. I was not suggesting that you change your packaging scheme. Instead I was suggesting that somebody with a firm grip on the packaging scheme and its possibilities reintegrated AUCTeX from scratch, more or less. AUCTeX has changed substantially since the last time anybody did that, and if somebody reseated its packaging from scratch, it might make life easier for the package integrator in future. AUCTeX in XEmacs has already fallen behind more than a year and is missing out important functionality. If somebody did the one-term effort of refitting it to the package structure of XEmacs, it might make updating it manageable for its maintainer again. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

David> I was not suggesting that you change your packaging scheme. I know you think that's true, but you're wrong. I've tried importing a recent AUCTeX (I think it was 11.81). Shoehorning AUCTeX into XEmacs's package building infrastructure would require substantial changes in one or the other. David> AUCTeX has changed substantially since the last time David> anybody did that, Since 11.81? If so, I'll give it another try. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

David> So you essentially say that starting with AUCTeX 11.81, it David> is not possible at all to create an XEmacs packaging of David> AUCTeX. Small wonder then that Uwe did not succeed in David> doing so. Not in a couple of makefile variables and targets using the current infrastructure. I'm pretty sure it could be done using a tedious and fragile rearrangement of AUCTeX's code and data, but that's not at all desirable. I then got a bad case of real life before I decided whether to try special-casing AUCTeX or whether to try to find a general solution for several important "large, self-contained" packages (but other than AUCTeX the necessary options are in place and set up). In the long run I want to permit what I call "opaque" packages, which would have a standard place to register their entry points, namely $PKGROOT/opaque-packages/$PACKAGE/auto-autoloads.{el,elc}, which would be reserved for XEmacs package use. (A bit impolite, but I don't see how else to do it.) Otherwise the package could set itself up any way it likes under that subdirectory. It could register its datadir and infodir directly in auto-autoloads or through an install-me function called from the init file, for example. Packages which would "like" this arrangement a lot include JDE and Emacsspeak, and I believe, AUCTeX. It shouldn't be that hard to do, except for the packager-oriented documentation, and functions to do the kind of consistency checks we now do in our "mandatory" structure. Both of those are likely to be tedious, and I don't understand the run-time initialization process for packages well enough yet. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

David> Another thought aside: upstream by now is at version David> 11.83 and distributes a precompiled XEmacs package at David> <URL:ftp://ftp.gnu.org/pub/gnu/auctex/auctex-11.83-pkg.tar.gz>;. David> It would probably make sense to take a look at it and David> model the procedure how the XEmacs team chooses to David> organize its CVS packaging from there. It does not David> seem to make too much sense to invest a lot of time David> into polishing the structure of 11.55 when 11.83 with a David> working version of preview-latex has been out for David> almost a year. David> I think part of the problem why Uwe has not yet been David> able to complete the transfer to a new version which David> now includes preview-latex is simply that the CVS David> repository structure (basically done for version 10.x) David> and the AUCTeX source structure have drifted apart, and David> it is becoming increasingly hard for the XEmacs package David> maintainer to keep what may partly be old cruft stepped David> up to the new requirements. More or less, I tried that several month ago and run into trouble precisely with preview-latex. Unfortunately my workload did not allow me to continue with my attempt. I thought may be this summer, but as things are it is very unlikely that before the beginning of September I will find the time to give it another try. So anybody with more skills and time is more than welcome to try it. [1] Uwe Brauer [1] Btw I tried the xemacs pkg (I think it was 11.81 but I am not sure) as catered by the auctex team and also run into problems. It is most unfortunate that I even do not had/have the time to send a decent bug report)