Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable)
On 25 Jun 1999 18:30:37 +0900, SL Baur <steve(a)xemacs.org> said:
As far as a programming API goes, the only item that is important is
#2, #1 and #3 should be handled automagically and correctly by
packaging support code in XEmacs and thus should be ignored by a
package, ie. a Lisp package on XEmacs can *always* assume that
1. It's source code is in the load-path; and 2. It's helper scripts
and binaries are in the exec-path.
Have I missed anything?
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