From xemacs-m  Tue Apr 22 14:33:26 1997
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55])
	by xemacs.org (8.8.5/8.8.5) with SMTP id OAA17725
	for <xemacs-beta@xemacs.org>; Tue, 22 Apr 1997 14:33:25 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id PAA28803; Tue, 22 Apr 1997 15:33:01 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.8.0/8.6.4) id PAA10946; Tue, 22 Apr 1997 15:32:59 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: Re: Goals for the packaging system
References: <vwm3esogoho.fsf@calico.cis.ohio-state.edu>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 22 Apr 1997 15:32:56 -0400
In-Reply-To: Pete Ware's message of 18 Apr 1997 14:44:19 -0400
Message-ID: <vwm4tcyluon.fsf@calico.cis.ohio-state.edu>
Lines: 80
X-Mailer: Gnus v5.4.37/XEmacs 19.15

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

> 1. XEmacs core

Some discussion about what should go here. [Does it matter?]

> 2. XEmacs SUMO:  All the packages at ftp. xemacs.org in one tar file

> 3. Package installation:

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

Since this file is included with XEmacs, it is at least as secure as
the original package.  The problem then seems to be how to make the
package downloading reasonable secure and fast.  Following, is a
suggestion for the file format:

((package-name
	(version-info
	 md5-checksum
	 (site-name path-to-package) ...) ...) ...)

So, an example might be (for only two packages; it extends to more):

((auctex
	(9.6m
	 f7119968ab86e42fb60030918d8b4d06
	 (ftp.sunsite.auc.dk /pub/emacs/auctex/ftp/auctex/auctex-9.6m.tar.gz)
	 (ftp.xemacs.org /pub/xemacs-20.1/packages/auctex/auctex-9.6m.tar.gz)
	))
 (w3
	(1.103
	 0ae103e96b372f0be770edebc23637ac
	 (ftp.xemacs.org /pub/xemacs-20.1/packages/w3/w3-1.103.tar.gz))))

I didn't bother to make it directly lisp readable although that seems
reasonable.

On load/require:
	If it isn't found in load-path:
		Ask the user if they want to download it:
			(they can either be prompted once, once per
			session or each time)
			Do the download
				a. Either use efs
				b. Use an async ftp process
			Verify the checksum
			Perform the installation (see below)
			Make old version invisible (i.e. prefix it
			with ".")

The installation process is independent of the download step and can
be improved/modified as needed once the above is working.

Perform the installation
a. Either in user's directory or system if person can and should
   access
b. Install in directory:
   .../package-name/version-info/
c. Add appropriate directories to load-path, Info-dir, exec-path

There is probably more to the installation step depending on the final
packaging system.  Options might include doing some configuration,
compilation, byte-compile, reading INSTALL files, site wide
customization (detect a site-custom.el file, eval it, then run custom
on it), ...

One could make new XEmacs lisp only releases by adding a new package
file (from the developers end).  People could update be grabbing the
new version and running some lisp code that updated everything already
downloaded.  I suppose the package file itself could be a version.

--pete

