Re: package site information more dynamically updateable
Stephen J. Turnbull wrote:
>>>>>"Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>>>>
>>>>>
Ben> yes, we should put xemacs-base into core.
I disagree. That will just bite us later with shadows and
backward-and-forward incompatibility. We'd be much better off
defining reasonable interfaces where we can and moving that stuff
_out_ of core, while providing a facility for installing minimal
packages or SUMOs from the distribution tarball. Things like URL
fetching etc are perfect candidates, since they're basically defined
by RFCs.
moving core stuff out of core just introduces more and more dependencies
between core and packages. if we maintain the stuff anyway, and its
critical to the core, there's zero point in it being in the packages.
On the other hand, our specific UI features are candidates for moving
back into core (I'm thinking specifically of annotations and fields),
if we can't standardize the APIs well enough to make them "public
stable".
I know having stuff in packages is annoying to you, Ben, but I believe
that the prospect of working with that big ball of mud we call "core"
is a prohibitive deterrent to a lot of people who might otherwise
contribute an occasional fix.
what's your evidence? has it stopped contributors to gnu emacs, where
there is even more in the core?
Ben> yes, we should switch to an http package installation
Ben> system. (really really really; http is *much* more reliable
Ben> than ftp these days and works through firewalls consistently)
This would be a lot easier on the users if package-get were itself in
a package.
why? it has to get implemented, either way. core or package won't make
much difference except that putting it in a package means someone has to
go to extra work to implement the "put the packages in the core
distribution" bit. will that be you?
ben