package site information more dynamically updateable

[Ben Wing]

Stephen J. Turnbull wrote:

>>>>>>"Ben" == Ben Wing <ben at 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