Re: PUI manages 3rd party packages: more RPM or DEB like
Hello
I think I wrote most of the relevant sites you mentioned, before going
to politics an important technical question:
1. In my understanding a 3rd party pkg could be installed either in
~/.xemacs/xemacs-packages
OR in
/prefix/lib/xemacs/site-packages
(my experience is entirely based on x-symbols, which however is
recommended to be installed in ~/.xemacs/xemacs-packages).
Now I read to my surprise in the documentation
</P>
<DT><VAR>XEMACS_STAGING = ${XEMACS_PACKAGES_BASE}/../Packages</VAR>
<DD>Set this to where you want normal packages to be
installed to.
So here I have to chose one of the possibility mentioned above.
furthermore
<DT><VAR>symlink =</VAR>
<DD>Set this to 't' if you want to do a "\run in place""
Setting this doesn't work well with 'make bindist'
<P>
This seems to be too bad. If I understand correctly a maintainer of a
3rd package has to make his decision where to install the package and
there are pro and cons for either solution.
Stephen J. Turnbull writes:
package-admin-delete-binary-package is non-interactive, thus
doesn't
count as part of PUI. That is probably easily fixed, not by changing
that function but by wrapping it in something to give it sane
arguments and get confirmation, etc, in package-ui.el.
If you look at package-ui.el, you'll see that list-packages
unfortunately uses package-get-base for the package list itself, and
does not consult packages-package-list to find out about local
packages. This is probably also easily fixed. I think that for
installation of 3rd party packages, we just set them up the way
Pre-Releases is set up. The packager provides a local
package-get-base list, and Tools | Packages | Sites needs a way to set
up 3rd party sites.
If this is the case I strongly to suggest to release this as soon as
possible, could greatly enhance the production of 3rd party package,
because up to now there is the de-instalation problem.
1. "Broken packages" means "we cannot guarantee there
will be no bugs
if you do this", in fact, you can be pretty sure that you will run
into bugs (the always inscrutable "can't call macros from compiled
Lisp" variety).
Ok
Ville Skyttä writes:
> 3. Explain under which conditions a 3rd party package enter the
> circle of official Xemacs packages. I can only think here of
> X-symbols which has been ignorated for years.
In short, an XEmacs package needs a maintainer. Convince the author to
help out or volunteer yourself. There are already too many packages
with xemacs-beta as the maintainer (volunteers welcome with these as
well), a good example of this would be the auctex case you refer to
below. See also
<http://www.xemacs.org/Develop/cvsaccess.html#committers>
Given the explanation of Stephen, the maintainer, even if he/she
provides a packages has to re generate it with slightly modified
Makefiles.
As for x-symbol, I try to contact Christoph.
As for auctex and preview latex.
David has explicitly said no to maintaining the XEmacs auctex
package
[1]. And nobody else has volunteered. So, it might happen
someday(tm). Personally, I don't want to touch it because I don't use
or know TeX; I'm limited to applying obvious bugfixes to it only.
I know TeX but it seems to me more a question of lisp, which I might
not know sufficiently, in any case I volunteer for auctex. I think
this is important enough especially now that there seems fresh air in
the development by David, and because preview-latex badly needs a
recent version of auctex. (As for preview-latex we will see, since
this is already in pseudo pkg form)
As a starting point could you send me the relevant makefiles and rules
files you have used so far, this would greatly speed up my learning
curve.
Uwe