Package system improvements!? (was: symbol's value as variable is void: allow-remote-paths)

Mats Lidell writes: There is also some beginning support for including a tarball of packages in the source tarball (etc/bundled-packages/). The main issue with doing something immediately is dealing with installation, because there may be preinstalled packages in an "unexpected" place. Ie, the default is /usr/local/share/xemacs/xemacs-packages, but people with a distro install may have /usr/share/xemacs21/xemacs-packages or users upgrading from 21.4 may have them in ~/.xemacs/xemacs-packages. Unfortunately, the packages *do* need to be installed, so that's not something we can really get around. It would be a real disservice to users if they got multiple installations of packages, especially if some are "full" and others are bootstrap ("crippled" for normal use). Basically, what needs to be done is to come up with a reasonable list of places where packages *might* be installed. Offhand, I think $prefix/lib/xemacs #### system packages #### $prefix/share/xemacs /usr/lib/xemacs /usr/share/xemacs /usr/lib/xemacs21 # Debian /usr/share/xemacs21 ~/.xemacs #### user or devel packages #### $srcdir # Ben's and maybe Mike's run-in-place style $srcdir/.. # what *I* think makes sense ;-) $site_lisp plus anything in --with-system-packages or --with-user-packages should be checked for existence of {xemacs,mule,site}-packages directories. (I'd seriously deprecate --package-path, and of course --with-legacy-packages would be ignored, for this purpose.) If more than one is found by configure, the user is warned that multiple package hierarchies were found, and they are listed. The bundled packages would be installed in $system_packages if the user has permissions, otherwise in $user_packages. If package installation locations are *not* specified, then the user is warned and no package installation is done. Something like that, anyway. :-) Tarball support doesn't help for hg users, but that's a smaller problem in the sense that we can probably create a xemacs-jupiter (the biggest imaginable solid object, even though it's mostly vapor -- sounds a lot like XEmacs, no? :-) hg repo which does nothing except contain the xemacs, xemacs-packages, and mule-packages subrepos. In fact that might be the appropriate thing to do with the xemacs-beta repo (why was that recreated? it's pretty pointless in current practice), since that would mean that xemacs-beta users would get a well-known environment. Alternatively, we could put xemacs-packages as a subrepo in the xemacs repo, but that has some obvious issues (which may be trivially resolvable, but I need to think about it before I'm willing to sign on to that strategy). Also, hg users can be expected to be more sophisticated/willing to spend more effort, I hope. An alternative would be to move the core xemacs repo into xemacs-core, and make xemacs repo itself contain xemacs-core, xemacs-packages, and mule-packages. This is just broken. We *need* to get xemacs-base and EFS into the tarball distribution. The strategy above would allow the xemacs.tar.gz to contain only the bootstrap packages (efs and xemacs-base for sure, probably dired IIRC, and maybe a few others, eg, from mule-packages), and a separate xemacs-jupiter.tar.gz to contain all packages, simply by having {bootstrap,xemacs,mule}-pkgs.tar.gz in the etc/bundled-packages directory of the source tree. "bootstrap" would always be present (small). Fixing the message is easy, I think. We just do an explicit require of efs in any library that references its variables. The require will fail, and make the problem apparent. Probably the only one that really matters is allow-remote-paths. I've thought about that, and came to the conclusion that it doesn't work on most distros, as there's no guarantee that the devel packages are installed. It's better to use ftp, wget, and/or curl commands for basic download support. Anyway, I did libcurl support (and neon as well) years ago. Nobody showed any interest (including me; I thought it was a great idea but didn't really have a use-case personally). The FFI branch (N.B. contributed by Steve Youngs, although the commit record may show my name) also includes basic ffi-based libcurl bindings. Nobody showed any interest. The modularized libcurl and neon bindings are in a separate git repo which I plan to update and convert to hg over the winter break. These are not ready for prime time IMO because they depend on an ugly change to core to support URL parsing and creation. Also, neon depends on some xml library, which we should expose bindings to IMO (but that can wait). The FFI branch is already in hg, but on Debian. Get it with hg clone http://anonscm.debian.org/hg/xemacs/xemacs-ffi Note that I don't know how practical it is to use libcurl on Windows; at least you'd need to deal with Cygwin and non-Cygwin, which would suck massively and I personally have -100 level of interest in porting my libcurl stuff to Windows (sorry). If there's a native Windows facility for downloading remote URLs, that probably should be used instead. libffi is also a non-starter for Windows AFAIK, although it's part of the GCC project IIRC, it does have substantial system dependency. OTOH, as long as we have volunteers producing Windows installers, this is pretty much a non-issue for Windows. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta