I'm making progress toward resolving the cleanup problems I have
moving from 21.4 to the 21.5 beta. To avoid having to dig through
several e-mails with different subject headers and to deal with
one thing at a time, I'm starting a new thread.
Thanks to the several who gave suggestions regarding getting my
packages updated. Someone suggested doing this:
(setq efs-ftp-program-args (append efs-ftp-program-args '("-p")))
I've never really understood what passive mode is in FTP. I went
out and read an explanation and still don't. Doesn't matter. I
seem to recall from previous experience that it doesn't hurt to
have it running. Nonetheless, I eval'ed that and stuck it in my
init.el in case I need it again, but commented out.
More importantly, I think, is the clue that
ftp.xemacs.org is
broken. As per Stephen's suggestion, I selected
ca.xemacs.org,
which I guess is the "nearest" mirror -- probably closer than
wherever
ftp.xemacs.org is (I'm in central Ohio) -- and that
enabled me to get an index, which I put in ~/.xemacs.
The first time I tried to update packages, it gave me an error
that it couldn't write the directory. This makes sense, given
that the packages are now in /usr/local space and I installed
them using sudo.
To get around this, I had to go to a command line and simply did
chown -R lnewton: on /usr/local. (There's nothing else there but
xemacs stuff.)
Although it apparently works right that way, it strikes me as
philosophically wrong and broken to go into /usr-land and start
changing ownerships and permissions. Isn't there or shouldn't
there be a way for the elisp to detect that when a directory tree
exists but is unwritable it almost certainly means that it needs
to be updated by root, and so should prompt for a password?
And while I'm at it, I had to answer some questions about where
to put the package index, which is now in my .xemacs directory.
I didn't look closely enough at what all it was telling me, but in
retrospect I suspect it's the same problem, that it wanted to put
the index with the packages but couldn't -- but intelligently
allowed me to put it in .xemacs. I should remove it out of there
and do the process again to see where it puts the thing.
(I hate having stuff in my face in a directory that I don't use.)
As far as I can tell, based on the dates that now exist in
/usr/local/share/xemacs/xemacs-packages/lisp, everything worked.
And it looks like only about a dozen packages have been updated
since the sumo was last created. (July 27, 2010)
Apparently it's not something I have to worry about very often.
Off to slay the next dragon.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta