Re: include SUMO?

Anders J. Munch writes: --without-FEATURE is equivalent to --with-FEATURE=no. It's not the safer choice yet. There are known performance problems, and several aspects where Mule is not fully implemented (eg, in tab controls with Xft). Because it is the future direction, we'll probably experiment with it in the beta series in the near future, but I expect this to cause some pain to some testers. The question is whether we should fix the known problems before doing that, or Just Do It and let the users scream at us until we do fix the problems.<wink> By "maintain", I mean "fix, improve, and release". No maintenance, no improvements of any kind, let alone in distribution. :-) Why should it? The point is not that installing the packages via the package manager is better than downloading a single tarball, it's that creating a single tarball is costly to the developers, and has some downsides for the users as well. Consider: XEmacs N is released with SUMO M. User installs. XEmacs N+1 is released with SUMO M. XEmacs N is not broken, user ignores. SUMO M+1 is released. User's favorite package is upgraded, user installs. User tries package X, likes it, but some features require XEmacs N+1, XEmacs N is now broken for this user. User installs XEmacs N+1, downgrading all packages to SUMO M. Oops. Unfortunately, there cannot be any such thing. Not until there is Linux World Domination and One True Distro to Rule Them All. We can and should fix the documentation to make an unambiguous *suggestion* of 1. Download xemacs-$version.tar.gz. Unpack in /usr/local/src. Then do: ./configure {options except install directories}; make; make install 2. Download xemacs-sumo.tar.gz. Unpack in /usr/local/share/xemacs/xemacs-packages. 3. Optionally download xemacs-mule-sumo.tar.gz Unpack in /usr/local/share/xemacs/mule-packages. This is near the top of my list (I'm presently trying to wrap my head around documenting and fixing bugs in the syntax code). 2 and 3 could be automated, but it will require checks on sanity of install directory options *and* for the presence and version of existing packages (including traditional but FHS-violating locations) or we really haven't improved things -- more convenient for first-time users, yes, but confusing and potentially data-destroying (what if a user has edited packages in the XEmacs system tree? M-x find-library makes that easy to do!) for existing users who upgrade. This will be non-trivial given the plethora of standard GNU options for installation directories, the existence of a few XEmacs-specific options like --with-prefix=no, and the fact that load-path is computed at runtime rather than baked into constants determined by the configure script. I would be happy to review patchs to configure.ac and Makefile.in.in to implement this, but be aware I will veto anything without most of the checks mentioned above. This makefile stanza: standard-install-packages: cd /tmp wget http://ftp.xemacs.org/pub/xemacs/xemacs-sumo.tar.gz wget http://ftp.xemacs.org/pub/xemacs/xemacs-mule-sumo.tar.gz cd /usr/local/share/xemacs/xemacs-packages tar xzf /tmp/xemacs-sumo.tar.gz cd ../mule-packages tar xzf /tmp/xemacs-mule-sumo.tar.gz has no hope of getting approved as-is. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta