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> It would probably make sense to take a look at it and model David> the procedure how the XEmacs team chooses to organize its David> CVS packaging from there. We've been through this before, and the situation has not changed. The XEmacs package system has two purposes: (1) to provide a convenient installer for users, and (2) to provide a consistent, modular framework for administration, development, and quality assurance of packages (as opposed to the packaged code itself, which can be, and often is developed and maintained outside of the package system). The strategy you propose is not compatible with (2). -- 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> 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)

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Well, you know my opinion about a different distribution mechanism (CVS instead of ftp), and having mirrors which only mirror the binaries, in connection with the GPL clause If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. All GNU/Linux distributors distribute source packages _along_ with the binaries or from the same directory hierarchies. But we have been through this already. I find that somewhat clashing with your previous contention that "complete corresponding machine-readable source code" need not include the package-specific scripts and files (namely not the framework, but the specific files integrating AUCTeX with that framework) you created for building the package. Whatever. We have been over this already and it is abundantly clear that you will not cede anything which would require work to fix. Letting this drop, still the original question remains why you would want to offer files like FAQ, INSTALL and so on compiled with different options than those of the source distribution, and thus being different from those in the source tarball. I don't see what it buys you not to use the -D rawfile switch in the intended way. While you are, of course, free to break the readability of those files in any manner you wish to, it is hard to see the point in doing so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum