[Bug: 21.4.15] Error in PACKAGE-GET Follow Up

[David A. Cobb]

D'uh.  Yes, I caught the load-path-shadows thing myself, /after/ I had 
sent the report.  Fixed that and, at least, changed the error.
Originally, the program errored out on a wrong-argument-type, expecting 
a list and receiving the site-name ("ftp.xemacs.org") as a string.  I 
erroneously thought the backtrace would go with the error report.

I have found some strangeness, and I still cannot successfully fetch a 
package update.

1) The initial state of  the  customize variable "Package Index File 
Location"  is set to the content of $EMACSPACKAGEPATH.  But when Xemacs 
wants to save an index file, a PATH won't do.  I cut it down to the 
xemacs-packages directory.  That still doesn't seem right because there 
could be mule-packages in the download - no?   Something like 
/usr/local/$EMACSVERSION/etc  -- designating a machine-specific data 
directory seems more probable.

2) The customize variable for "Package Repository" has a docstring "The 
remote site to contact for downloading packages . . ." -- considering 
that there are about three other lists of sites, is this correct??  My 
concern here is that I also use the Windows Netinstaller, so I do have a 
local repository of zipped up packages --  I'm not quite sure where to 
put that or whether to use the parent Repository directory or the 
"<Repository>/packages" subdirectory.  Right now I've just nulled that 
'feature' out.

3) Consider the attached content of the ftp buffer.  The efs  tries to 
cwd into the full pathname of the index file.  That certainly ain't 
right!   Obviously it should cwd into the parent directory and get the 
index-file.  I suspect that is why it finds the resulting index empty 
and  fails as shown in the attached backtrace.

4) As long as I'm on the subject, is there a way to make the pui site 
fixed?  As it is,  it requires to  be reset every time I want to 
update.  But I nearly always want to use the same site (either 
ftp.xemacs.org or ftp.us.xemacs.org).

Steve Youngs wrote:

>* Superbiskit  <Superbiskit at cox.net> writes:
>
>  > Set Tools->Packages->Set_Download_Site->US (Main US Site)
>  > Tools->  Packages->List_and_Install
>
>What is the problem?  You haven't mentioned anything about what is
>wrong. 
>
>  > Load-Path Lisp Shadows:
>  > ----------------------
>  > (/usr/share/xemacs-21.4.14/lisp/package-get
>  > /usr/share/xemacs-21.4.15/lisp/package-get
>
>Regardless of whatever problem you are seeing, this is _*WRONG*_.
>You're installation is screwed!  You should _*NEVER*_ have more than
>one core lisp directory in your load-path.
>
>It is interesting that the subject of this bug report is "Error in
>PACKAGE-GET", and here we have package-get.el being shadowed by an
>older version.  Fix this and I bet you'll fix your problem.
>
>  
>

-- 
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace, I am a Christian man; by my actions a great sinner." -- The Way of a Pilgrim: R.French, Tr.
Life is too short to tolerate crappy software!



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ftp-anonymous-xemacs-org.txt
Url: http://calypso.tux.org/pipermail/xemacs-beta/attachments/20040303/99fd200c/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace_package-get-maybe-save-index.txt
Url: http://calypso.tux.org/pipermail/xemacs-beta/attachments/20040303/99fd200c/attachment-0001.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Superbiskit.vcf
Type: text/x-vcard
Size: 212 bytes
Desc: not available
Url : http://calypso.tux.org/pipermail/xemacs-beta/attachments/20040303/99fd200c/attachment.vcf