"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Nonsense. Our XEmacs package which you can download from <URL:ftp://ftp.gnu.org/pub/gnu/auctex/auctex-11.82-pkg.tar.gz> is already completely in the correct form, including autoloads, directory arrangement, package metadata and MANIFEST file. It does not get simpler than that. It is a finished, properly built and working XEmacs package, with all the required files in the right places. "Distributing" it means putting it on the ftp server, that's all. No repackaging, rearrangement or anything required. You bet. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Michael Sperber wrote: Hi Mike: Who are you asking that to? Are you wondering about the original bug report or Stephen's post? Thanks, Rodney

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: For crying out loud, it is not even possible to check the same directory into two different CVS archives, even if the directory layout matched that of the XEmacs package repository perfectly. I suggest that you either get a clue about AUCTeX by looking at it, or refrain from commenting on its details. If it is not a big deal, what are we to gather from the fact that it has taken years to find a volunteer to do it, and that he needs several months on average to synch, even though by now upstream generates complete packages? Big deal or not, it does not appear to solicit people wanting to touch any of it, so at least it is apparently a prohibitively high psychological barrier. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: The 11.5x framework is _utterly_ different from the 11.14 framework (an autoconf-based installation was introduced), and the 11.8x framework still is _utterly_ different from that (preview-latex, a package with LaTeX style files and other niceties was introduced). Much much more than 11.14 differs from 10.x. So you are completely out of your depth making statements about the current state of AUCTeX. Your experience is outdated by years. Things have changed a lot since then. There is enough of a difference between 11.x and 11.x that users care. ConTeXt is supported, PDFTeX is supported, Source Specials are supported, syntax highlighting is much improved, preview-latex is included, macro folding is supported, many more styles are supported... The list goes on and on. The difference is much much more than between 10.x and 11.0. Again: if you can't be bothered to bring your knowledge up to scratch, you should refrain from parading it. Get real. Most of the work is done upstream, to the point that we build a complete XEmacs package. Uwe would not have an inkling of a chance if we did not support XEmacs upstream. And that still is not enough to have the stuff moved into XEmacs with suitable swiftness and quality. The party that can cater for quality control in a reasonable manner is upstream. According to the wishful thinking in the XEmacs policies, yes. And exactly because it does not work, it becomes reasonable to reconsider "the way it's supposed to work", namely the policies. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: So I am not supposed to take issue with your presentation of outdated and invalid data about AUCTeX internals until the review board sees through it on its own? Whatever. The complete tarball as well as the prebuilt XEmacs package are available from <URL:ftp://ftp.gnu.org/pub/gnu/auctex>;, so it should be reasonably easy for anybody _willing_ to inform himself to get the stuff, take a look, and see whether he can imagine a process of updating the XEmacs repository with the actual stuff in a meaningful manner that would have less probability of error than just taking the prebuilt package maintained upstream. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Serves me right. While I suppose they will, I'll just give you the fast run-down here first so that you don't waste time. It seems that you have mostly taken a look at the source rather than the installation instructions. Following the installation instructions would leave you with the well-tried procedures. And that means that you are on rough ground. This does not mean that AUCTeX per se is broken (it works if you follow instructions), but that stuff that is not in use ordinarily might not work. But it will not harm if we fix those things. That's not unusual for a configure/make installation. Either remove previous installations, or configure for a different target directory. Please note that --without-packagedir requests to ignore the XEmacs package system and its structure completely. This particular option should not really be used and is basically untested. It might be saner to remove it completely. Unfortunately systems like Debian have a weird non-package layout for some stuff, so it might actually be needed in some cases. So we should make it either work, or throw it out. Quite so. One can help with overriding options, but this is definitely a bug. Well, if you take a look at the installation instructions, you'll see that building a binary package is not mentioned in there. The normal configure/install basically has the effect of building and installing the package in one step: you can remove it using XEmacs' package manager after that. The xemacs-package target is for maintainers only. It requires using the maintainer-only tar-ball target before, and tar-ball checks out a fresh copy from CVS before building. Since this stuff is undocumented and maintainer-only, it is not a problem per se that it only run's on the maintainers' operating systems. While this has not yet made it into the docs (as we just have started providing the XEmacs tarball), people are not supposed to build a separate package file for themselves, but rather are supposed to get a prebuilt package _if_ they want to have a standard package setup. It is quite pointless for people to build a package which will look just the same as a prebuilt package. Building and installing AUCTeX from sources is not a problem. You just should not use -without-package-dir explicitly in order to get a deprecated layout. Building and _not_ installing a binary XEmacs package is what users should not attempt. It is quite undocumented and requires CVS access. It is not clear that it would be beneficial for users to build a package file with the same name as our official XEmacs binary package but possibly different contents. I'd rather install the thing right into the package tree without making it a separate file. I don't really want to remove the maintainer-only targets from the Makefile, but maybe we should do a better job of marking them as intended just for internal use. Which would be an indicator that the target with which they were built works to some degree on the maintainers' machines. We had positive reports from the package, anyway. Thanks for taking a look. It will help to improve the AUCTeX building experience, but still leaves the question of how one can with the least amount of effort import the stuff into the XEmacs package repository. The current procedures require far too much manual labor, given that we essentially start with a viable end product already. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

David> It seems that you have mostly taken a look at the source David> rather than the installation instructions. I did look at the installation instructions, but they don't serve my needs as a user (I normally _do_ build and keep package files for all XEmacs packages that I'm interested in, as opposed to just updating to the latest for completeness). Of course at the moment I'm wearing my developer's hat, as you realized, but I give several valid use cases for users below. David> That's not unusual for a configure/make installation. It is nowadays; most projects support installation to an empty $prefix, and almost as many support $DESTDIR. I don't think this is hard for AUCTeX to provide, it may even simply be a minor doc change: David> Either remove previous installations, or configure for a David> different target directory. That's insufficient, as I pointed out in my bug report. configure checks that you have a valid installation. You need --xemacs-packagedir to point to an existing directory, or for xemacs-packages to exist under $prefix. Not obvious from the installation instructions---they say that's sufficient, but it's not obvious it's necessary, and since XEmacs tools make no such check, XEmacs users are fairly likely to make the same mistake I did, I bet. I guess my suggestion is to make --with-xemacs-packages the flag for an XEmacs installation, and require that it point to an existing directory which should be xemacs-packages for a direct installation. --with-emacs would be allowed to point to xemacs, and could be used to specify a non-default xemacs (eg 21.5 vs 21.4). If --with-emacs points to XEmacs and --with-xemacs-packages is _not_ present, my preference would be to go ahead and try to install to site-lisp. But you seem to prefer to remove that option, which is OK as long as it's documented and --with-emacs=xemacs --without-xemacs-packages is a configure error. --with-xemacs-packages (no arg) would require that $prefix/lib/xemacs/xemacs-packages exist, and install there. ($datadir/xemacs/xemacs-packages doesn't work by default, XEmacs isn't FHS conformant yet, and $libdir/xemacs/xemacs-packages doesn't seem to be an appropriate thing to do since that violates FHS.) --with-xemacs-packages=existing-tmp-dir could be the undocumented way for a maintainer to install for a tarball, although it's probably better to have a separate option for that if you don't want users doing that. If you're going to use a separate option, it's a good idea to use the word "staging" in the name, as that will be familiar to XEmacs users who build from CVS. David> Please note that --without-packagedir requests to ignore David> the XEmacs package system and its structure completely. It David> might be saner to remove it completely. Sure. I was using it because I wanted to see what the layout and install process looked like for a generic Emacs install, but that's not your problem---it's easy enough for me to install Emacs. And it's acceptable to remove since (as the original thread shows) site-lisp is deprecated and may not even exist in typical XEmacs installations, while XEmacs modern enough to work with AUCTeX must have xemacs-packages to have enough functionality to make sense to use with AUCTeX. David> While this has not yet made it into the docs (as we just David> have started providing the XEmacs tarball), people are not David> supposed to build a separate package file for themselves, David> but rather are supposed to get a prebuilt package _if_ they David> want to have a standard package setup. It is quite David> pointless for people to build a package which will look David> just the same as a prebuilt package. Heh. Are you the same dak(a)gnu.org who was worrying about GPL violations because our XEmacs binary packages don't include the package build infrastructure a few months ago? Sarcasm aside, there are several valid use cases. (1) Rewinding to previous versions, which may be necessary for reasons completely out of AUCTeX's control. This is important for mission-critical packages, and for academics and other technical writers, AUCTeX surely is mission-critical. Eg, I haven't been screwed by XEmacs packages recently, but just yesterday I updated my libmysqlclient15 from Debian, it was broken, the breakage caused exim to think it was failing to deliver although in fact the mail was delivered, and I was embarrassed by a half-dozen unnecessary resends. But that was all, because I still had the previous, working .deb in my apt cache. dpkg -i and everybody's happy again. (2) Using a package tarball to install to multiple hosts. (3) Maybe I want CVS AUCTeX for a new feature, even though release is some weeks or months in the future. (4) Maybe my local AUCTeX is currently not identical to upstream, but I want to merge upstream improvements. This is free software we're talking about. Why build from CVS in cases (1) and (2)? Any number of reasons: byte compiler improvements not backported to the stable version, different optimization level (yes, XEmacs has optional optimizations), etc. And some people just insist on building things themselves. IMO you want to make those people as happy as possible because they're the kind of users that turn into developers. David> Building and installing AUCTeX from sources is not a David> problem. It currently _is_ a problem if you don't believe in overwriting a working installation without backup, at least until the instructions make clear how to install to a different place which may not even exist yet. ("Use mkdir, dummy" is an acceptable response.) If you have package tarballs, it's as easy as cat pkginfo/auctex.MANIFEST | xargs rm -f tar xzf $BKUP_PKGS/auctex-$WORKING_VERSION-pkg.tar.gz If you don't, it's quite a bit hairier, unless you keep careful records of what worked, and can cvs update to an appropriate revision. Even then that's substantially more work and tedium. David> It is not clear that it would be beneficial for users to David> build a package file with the same name as our official David> XEmacs binary package but possibly different contents. I'd David> rather install the thing right into the package tree David> without making it a separate file. I agree with your suspicions about the package file name; we've needed to do something about the bogus naming scheme for quite a while. But we have differing opinions about the desirability of installing directly into the tree. True, for _most_ users that is precisely what they're going to do, and it's probably even the best thing for them unless they're really really paranoid. But for many users that is not going to be close to optimal. And I suspect those are going to be the kind of users you want to be as happy as possible with everything about AUCTeX, not limited to advertised functionality. IMHO YMMV, etc. David> still leaves the question of how one can with the least David> amount of effort import the stuff into the XEmacs package David> repository. The current procedures require far too much David> manual labor, given that we essentially start with a viable David> end product already. Just what do you think I thought I was doing? :-) I really think the right way to go is my "opaque-packages" proposal. The layout you've designed for AUCTeX in Emacs really makes much more sense than the one we currently demand, which is oriented to a large collection of small but interdependent packages. AUCTeX has few, if any, external dependencies on LISP packages, and I would suppose is rarely required by other packages. There's no reason not to provide a few autoloaded entry points and otherwise let AUCTeX find its internal APIs itself. This doesn't have pui support yet, but that won't be that hard to provide, and "cd /path/to/xemacs-packages; tar xzf auctex-pkg.tar.gz" is hardly burdensome as a transition strategy. -- 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.

* Vin Shelton <acs(a)xemacs.org&gt; writes: Excuse me? 21.4 has supported the site-packages hierarchy for years. I use it myself. Have done for ages. Even ~/.xemacs/site-packages/ works in 21.4. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

* David Kastrup <dak(a)gnu.org&gt; writes: Yeah, I realised my fuckup when I re-read my post (once it finally hit the list). I didn't know it existed. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

On 1/18/06, Steve Youngs <steve(a)sxemacs.org&gt; wrote: Does your path include site-packages/foo/lisp, site-packages/bar/lisp, or is it site-packages/lisp/foo and site-packages/lisp/bar? - Vin -- Whoever you are, no matter how lonely, the world offers itself to your imagination, calls to you like the wild geese, harsh and exciting-- over and over announcing your place in the family of things. Mary Oliver

Steve Youngs <steve <at> sxemacs.org> writes: Not on Windows: site-packages/lisp/bar are added to the load-path; while site-packages/bar/lisp are not. Rodney

On 1/18/06, David Kastrup <dak(a)gnu.org&gt; wrote: David, If I misrepresented your position, I'm sorry. - Vin