Re: [FAILED] XEmacs 21.2.15

[Sorry for the redundant copy but the mail to xemacs-beta bounced somehow. ] SL Baur writes: | Actually, 21.1 isn't incompatible in this fashion, Stephen and | the others were using pre-21.0-final mule-base packages -- if you live | on the bleeding edge and do not keep sufficiently up-to-date expect to | get cut once in awhile. There's no reasonable precaution we can make | and we cannot avoid changing things in test releases when they need to | be changed. In fact this is a good experience (at least for me) that helps trouble shooting and understanding packaging process. My guess is that we'll see more of these reports when people start to upgrade packages or upgrade XEmacs binaries. Maybe some comments should go to the FAQ. | We probably ought to pitch everything unnecessary to building right | now to avoid this sort of thing in the future. Superfluous undumped | stuffs like apropos.el, cus-edit.el etc. shouldn't be in the core. I | have hesitated because of past squeals of pain, but I think the time | is probably right, now. The XEmacs core should only contain the | minimum files necessary for making an xemacs binary *and* to provide | for minimal vi-equivalent editing functionality. Everything else | should be loadable at run-time, that way it isn't bloat. Hm, I am not if this the right thread but if see some issues with the packages migrations/updates the way it is now: -- I am (and some other people) sitting behind a firewall which make it hard to download the files directly with XEmacs. So besides the possibility to choose a download site one should be able to specify a local directory name. BTW, if you have a very slow link or an unstable connection you also might want to transfer the file manually via ftp. It is not just because of the firewall. See below. -- If you install XEmacs as root (as well as the packages) nobody except root can update the packages (which can be a pain in the ass depending on the responsible sysadm). Further you cannot install the packages in a seperate directory if you wish to update the package as a normal user hiding the old sources. BTW, wouldn't it make sense to verify the directories the install/update process need to write have the right perms before I start downloading (GNUS took 30min to download before I got the permission denied).