Gregory Neil Shapiro <gshapiro(a)sendmail.org> writes:
/usr/local/src/xemacs/packages/src/xemacs-base-1.29-pkg.tar.gz ends
up
installing the package in that ../packages/src/ directory instead of
../xemacs-21.2.9/packages/ making the installed package unreachable.
Unfortunately this is a design problem combined with misconception
form your side [probably caused by lack of documentation]. Any subdir
of a known package hierarchy NOT in packages-special-base-regexp is
ALSO a package hierarchy[1].
When installing a package, the package tools default to where
xemacs-base is. Unfortunately that won't work if we are installing
xemacs-base. Therefore the tools take (last late-packages). This will
typically be the subdirectory as you mentioned.
I believe ../packages/src/ was the current working directory
I don't think it has anything to do with the current working
directory, see above.
when the
package-admin-add-binary-package was executed but the command should
have used a package hierarchy.
By XEmacs thinking it _is_ a package hierarchy. Moreover it should
work with the packages installed there. It may be ugly, but it should
work.
The same thing happens when trying to use the package-ui. I had to
install
all of the packages by hand using tar.
That should not be necessary. The most important thing is to get
xemacs-base and mule-base in the right place after that the rest
should just work.
Have you read README.packages?
Jan
Footnotes:
[1] I think this is a mistake.