From xemacs-m  Wed Apr 23 11:49:57 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 LAA04678
	for <xemacs-beta@xemacs.org>; Wed, 23 Apr 1997 11:49:56 -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 MAA06116; Wed, 23 Apr 1997 12:49:54 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.8.0/8.6.4) id MAA10940; Wed, 23 Apr 1997 12:49:54 -0400 (EDT)
To: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
Cc: xemacs-beta@xemacs.org
Subject: Re: Goals for the packaging system
References: <vwm3esogoho.fsf@calico.cis.ohio-state.edu> <vwm4tcyluon.fsf@calico.cis.ohio-state.edu> <199704230821.KAA03474@daedalus.tnt.uni-hannover.de>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 23 Apr 1997 12:49:52 -0400
In-Reply-To: Heiko Muenkel's message of Wed, 23 Apr 1997 10:21:17 +0200
Message-ID: <vwmlo69k7kf.fsf@calico.cis.ohio-state.edu>
Lines: 52
X-Mailer: Gnus v5.4.37/XEmacs 19.15

Heiko Muenkel <muenkel@tnt.uni-hannover.de> writes:

> I think, that it should also be possible to get the latest version of
> a package. But this leads to some problems:
> 
> 1. An md5 checksum makes only sense, if it is stored in the core
>    XEmacs, so this is useless for package updates. Wouldn't a pgp sign
>    of the author be better for this propose? 

I opted for md5 as it is simple and doesn't rely on grabbing any
external info (i.e. the author's pub key -- although I must confess to
not being very up on pgp).  To announce new software you'd include the
md5 checksum.  Also, for such "one-off" type of upgrades, it might be
reasonable to not even compute the checksum (i.e. like must of us do).
I also thought one of the reasonable things to include is a simple way
to grab the new version of the packages file.

> 
> 2. A newer version of a package could break other packages, which uses
>    it. To overcome these problems we should implement one or more of
>    the following points:
> 	- the possibility to get the version of a package which was
> 	  tested by the XEmacs beta testers; this should be the
> 	  default, so that's more likely that novice users get a working
> 	  XEmacs;
That is exactly what the packages file accomplishes -- one just grabs
a new version of the file and run some lisp [this falls into the
"future" enhancement category] to get and install new
versions of packages that you already have installed (easily
determined by the directory names of .../package/version/...).

> 	- every package should contain also the versions of the
> 	  foreign packages, which are used for it and which are known
> 	  to work with it; there should be also a way to get all the
> 	  foreign packages with the needed versions;

These are good ideas.  Forgive me for harping on this but there are
really three independent steps for the new packaging:
	(1) Determining the XEmacs core;
	(2) Getting a package;
	(3) Installing the package.

I don't think we _have_ to get (1) and (3) right the first time --
anything we do there is going to be better than what we have now.  In
other words, I think KISS applies.  I think your ideas fall into
category (3).

Btw, when we do implement packages, it might be nice to keep stats on
ftp.xemacs.org about which ones are popular.  Based on that we
could move stuff into the "core" distribution in future releases.

--pete

