about obsolete packages

[stephen at xemacs.org]

Ren? Kyllingstad writes:

 > * Stephen:

 > >  The only solution acceptable to David is for us to distribute the
 > >  pseudo-package produced by the AUCTeX team verbatim.  I see no point
 > >  in that; 

 > Convenience for the users?  It would be there for the sumos, and available
 > in the package manager without any special configuration.  Pretty please?

And if I commit something to core that breaks it, what do you suggest?
If it's updated and is dead-on-arrival because of changes to 21.5 that
the AUCTeX team (which last I heard had *zero* regular users of XEmacs
in its core group) isn't up to date on, what do you suggest?  Where
should those bug reports go?  What do we do with those packages while
waiting for a fix?  I *definitely* don't think such packages should go
into the SUMOs.

As for "needing special configuration," IMO the package manager has
long been deficient in that respect; it should be improved to offer
all the versions of a package that it knows about.

Now, there are well-known problems that arise with 3rd-party Emacs
Lisp that is not built in a "clean" environment.  The XEmacs package
system has been very successful in forestalling most of those (thanks
in part to Mats Lidell's "smoke test", M-x all-hail-mats RET), without
the delays involved in waiting for a core release tested with all the
packages.  I don't want to give that up.

OTOH, there are plenty of packages that don't need "helium atmosphere
builds" to work acceptably well; AUCTeX is evidently one.  x-symbol is
another.  The package manager ought to support convenient installation
and removal of a "contrib" or "as-is" category of binary packages that
*we* don't care if they break or not (but mostly they don't ;-).  I
think that would be a better place to direct core developer effort
than dealing directly with AUCTeX (that currently doesn't build in our
"clean" environment).