From xemacs-m  Tue Apr 22 07:03:22 1997
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id HAA12417
	for <xemacs-beta@xemacs.org>; Tue, 22 Apr 1997 07:03:20 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 22 Apr 1997 14:00:12 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id NAA25718; Tue, 22 Apr 1997 13:59:05 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id NAA02757;
          Tue, 22 Apr 1997 13:59:03 +0200
Date: Tue, 22 Apr 1997 13:59:03 +0200
Message-Id: <199704221159.NAA02757@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: ware@cis.ohio-state.edu
Cc: xemacs-beta@xemacs.org
Subject: Re: Goals for the packaging system
In-Reply-To: <vwm3esogoho.fsf@calico.cis.ohio-state.edu>
References: <vwm3esogoho.fsf@calico.cis.ohio-state.edu>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Pete" == Pete Ware <ware@cis.ohio-state.edu> writes:

    Pete> 1. Much smaller XEmacs core.  2. Allow sys-admins to easily
    Pete> reach XEmacs SUMO 3. Allow users to gracefully
    Pete> expand/contract from/to core functionality 4. Allow lisp
    Pete> programmers to support packages independently of XEmacs
    Pete> 5. Reasonable security

    Pete> 1. XEmacs core - The core or level 0 functionallity should
    Pete> be the minimal to edit a text file in Fundamental Mode and
    Pete> to support other modes. 

    Pete> Not that anyone would view this as
    Pete> satisfactory, but just to define what _has_ to work:

    Pete> 	comm communications, networking, remote access to
    Pete> files data support editing files of data docs support for
    Pete> Emacs documentation faces support for multiple fonts frames
    Pete> support for Emacs frames and window systems help support for
    Pete> on-line help systems i18n internationalization and alternate
    Pete> character-set support internal code for Emacs internals,
    Pete> build process, defaults lisp Lisp support, including Emacs
    Pete> Lisp maint maintenance aids for the Emacs development group
    Pete> mouse mouse support terminals support for terminal types

I agree with you with the exception of what should be in the core. The
core should be more or less what you've written in your first lines
(not sure, if a Lisp edit mode must be there or not). The following
could be named as the basic-useful-add-ons and should be provided as
an additional tar file. As I said in my earlier mails: Let's give the
user the chance to decide, what is useful and what not!

    Pete>    - The typical stuff one expects c support for the C
    Pete> language and related languages extensions Emacs Lisp
    Pete> language extensions languages specialized modes for editing
    Pete> programming languages message processes process, subshell,
    Pete> compilation, and job control support tools programming tools
    Pete> wp word processing

    Pete> 2. XEmacs SUMO: All the packages at ftp. xemacs.org in one
    Pete> tar file
   
    Pete> 3. Package installation: I think this is the part that is
    Pete> going to generate the most design/heat.  Personally, I'd
    Pete> like a system with something like:

    Pete> 	- A file in the core distribution that includes a list
    Pete> of all packages at ftp.xemacs.org (and/or mirrors) and
    Pete> checksum/signatures for each package.  If a user want's to
    Pete> load something from this list, it can be installed by XEmacs
    Pete> which uses the checksum/signature to verify what it got is
    Pete> valid.  It can be darn close to automatic (i.e. prompt once
    Pete> per session, each time, never) and can either install it in
    Pete> the user's home directory, a temporary space or system wide.

    Pete> 	- Once a package is snarfed by a user, an easy way to
    Pete> install it.  Including munging of info and load-path
    Pete> variables.  This should be done independently of the auto
    Pete> grabbing of it.

    Pete> 4. The ideas&followups that Michael Harnois suggested about
    Pete> the directory hierarch seem reasoanble.

    Pete> 5. In addition, perhaps a way to easily snarf a new version
    Pete> of the checksum from ftp.xemacs.org to allow "blessed" files
    Pete> to be added.  This could also do the generic ==> specific
    Pete> version mapping as well and include the remote path for each
    Pete> package.

    Pete> --pete

