On 25 Jun 1999 18:30:37 +0900, SL Baur <steve(a)xemacs.org&gt; said: You can't assume that the helper scripts and binaries are in the exec-path if you intend to allow more than one version of a package to be around. <rant mode=full coherent=mostly> As packages proliferate, you *will* need to be able to say thinks like: "I'm the sysadmin, and user1 needs to use (require 'foobar '(atleast 3.8)) but user2 insists on having a (require 'foobar '(exactly 3.7)) because foobar 3.8 Breaks Really Badly if run with QuuzBaz 0.9.34. Normally, I'd tell them *both* to stuff it and store it in their own ~/.xemacs tree, except I *know* if I do that, 18 months from now FooBar 4.1 will be out, and we'll get to hear from all the 3.x users who can't figure out why something works for Joe in the next cubicle but doesn't for them. Of course, it's because Joe is getting the copy out of the latest SUMO I installed 3 weeks ago...." I'm not bitter, I've just spent too much time in the last 2 months dealing with hacked Solaris boxes because a Sun patch didn't close a hole, and SGI boxes hacked because users didn't apply the patches. At least 15 and 20 years ago, I could put up a new release of a compiler, store the old one off someplace in case a user had an upgrade problem, put out a note "Fortran 3.6 is here now, if you have a problem use the old 3.5 version stashed <here>", and I'd *know* that everybody was running the latest code except for the people wiht compatability problems, and I'd be able to track and help those people. Remember - installed version control on a personal workstation bears no resemblance to doing it for a large organization... </rant> Of course, XEmacs gets it right for itself - all its helper stuff goes into /usr/local/lib/xemacs-$VERSION. Now if we just enforce that a package's helpers have to live in packages/$PACKNAME/bin, we can just remember where we loaded it from, and find the helpers without having to deal with exec-path. And people wonder why I mostly just redo when a new SUMO comes out. ;) /Valdis