Re: Package system improvements!?
Mats,
A couple of suggestions:
1. improve the error message (probably what you were suggesting):
Something like what file, part of which package, is being looked
for, and in what places.
example:
Cannot find file xxx.xxx of package xxx in paths (list of places
looked).
Gives the guy with the error some things to look for:
-a filename to search for in his system
- package name the file is part of, so he knows which step went
awry.
-a place (or places) that it would be expected to be found.
-gives something to google for, when stumped.
2. improve the documentation by adding a paragraph mentioning
the error.
Example:
(from notes I wrote myself when solving this error last week)
"One error that may come up at this step is the minibuffer may display:
Symbol's value as variable is void: allow-remote-paths
The most likely problem to cause this error is XEmacs is not
finding the
2 packages (efs and xemacs-base) that we downloaded and installed in
previous steps.
Check first that the 2 packages were unpacked in the correct place.
Second, check carefully the ./configure options that you selected
before
compiling the XEmacs source code. particularly the options having to do
with paths. You may have to go back to the /usr/src/ directory and
assemble
a new ./configure command line, and start the install process over
from that
point, since the paths for your installation are set by running
./configure and
are compiled into your XEmacs executable."
Looking at those notes, the "unpacked in correct place" above should
probably have the correct place listed *right there* to be thorough.
Steve M.
On 12/02/2011 07:24 PM, Mats Lidell wrote:
>>>>> Mats Lidell<matsl(a)xemacs.org> writes:
> allow-remote-paths problems. I'm trying to get the package system
> working as it is currently designed. [...]
Looking into this again I realize I must have been very lost the last
time I looked at it. The thing is this. When you launch a binary
without any packages at all you get an unhelpful "Symbol's value as
variable is void: allow-remote-path" message.
Mats, when I got this same
error, it was not when running the command
xemacs,
but after running xemacs, then choosing (from the menu) either:
[Tools][Packages][Update Package Index]
[Tools][Packages][List and Install]
It may happen other times, but that was the only time I experienced it.
I then thought erroneously that we had some simple support for
download in the core and the first step was to see to that we don't
barf on allow-remote-path being undefined and then make the core
download work. This isn't the case. There is no core download. You
need a few packages to get going. (I knew this but maybe I had a bad
dream or something and forgot that ;-()
The docs does describe what steps you need to take to bootstrap into a
minimal set of packages for starting to use the package system. So the
info is there. I haven't really checked that the instructions are good
but they can be found.
I agree that *most* of the info is there, and it is pretty
good, but
(just my opinion)
there are some spots that need wrinkles smoothed out. For just one example:
on http://www.xemacs.org/Documentation/packageGuide.html under the heading
Installing by Hand, it lists the following command: |
gunzip -c ...../xemacs-base-1.27-pkg.tar.gz | tar xf -
I could not get 5 dots in a row to work, thought they might have meant
../../ or ... ../ or ../../../ or other iterations. I tried to
understand what was meant. I even (don't laugh) googled "...../" in
desperation, and just for the record "...../" has no results (grin).
Maybe they meant $prefix there or something. So I guessed what they meant
and got it wrong the first couple times, installing the packages
in the wrong place. I'd be embarrassed to admit that it took 3 evenings
working at it to realize that I guessed at that step, and that my guess
being wrong was the problem. I kept looking in other places for errors.
There are other wrinkles too, that is just one example that stopped me.
|
So what about possible basic improvements to the package system!?
- Provide some better feed back to a user who starts using the
package system without the basic packages installed. The Symbol's
values as ... message isn't very helpful.
However users who use installers on Windows or other distros will
hopefully find that the basic packages are already provided or
available to install through other means, eg the installer or the
distros package manager.
- Provide download capabilities in core such as use libcurl. This
would possibly allow a bare binary to download even the basic
packages.
Ideas?
Yours
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta