Re: elisp packages

Jan> Martin Buchholz <martin(a)xemacs.org&gt; writes: Jan> Are you sure that the Cygwin people forgot to put the packages on the Jan> CD? I really cannot believe that. It's incredibly easy to do. What other packages on the Net build and install `successfully', yet are effectively useless when actually used? It's all too easy for someone whose job it is to populate a CD with many `working' programs to repeat the algorithm ftp; tar -x; cd; configure; make; make install; copy to CD and consider the job finished when they get rc=0. For this reason the distinction between a `core' library and an optional separately installable library is so crucial. For example, I consider `libnet' the single most useful non-core library for perl. It is non-core (personal communication from the author) only for perl-internal political reasons. I would bet that *no* Linux distribution out there would distribute a perl that comes with any extra libraries such as libnet. ("Why not trust Larry?") As a result, scripts that have any pretense at portability at all would either not use libnet, or come with their own pre-built libnet library directory. Even if you have administrative control over all the machines that would use that script, you still have the hassle of having your script broken every time you upgrade the OS on your machine, because the upgraded perl fails to have its own libnet. It's annoying having your OS upgrade procedure contain another random step that's easy to forget. I consider it a mini-disaster that perl does not come with libnet. Fortunately for perl, many uses of perl use just the standard core functionality. Few users of XEmacs just use the current `core' functionality. Jan> Frankly I think the package system hasn't had a fair chance yet. Our Jan> communication, QA and maintenance crisis has amplified it weaknesses Jan> while not allowing us to profit from its benefits. Jan> We actually have had a split tarball system for the binaries for ages Jan> and I have seen relatively few complaints about that. The only real Jan> conceptual difference was that the binaries complained loudly if they Jan> couldn't bind the stuff from xemacs-common. It's true that having good READMEs and having the relevant files in a common directory helps a *lot*. Complaining loudly and making it clear that XEmacs was incorrectly installed is a good clue. The worst thing about the current XEmacs distribution is that it builds, installs and even runs without complaint. It seems `obvious' that the program maintainers intended the editor to be used that way. Yet we the maintainers know that it's actually useless for doing any real work. Martin