Date: Wed, 12 May 1999 20:46:43 -0400
Message-Id: <199905130046.UAA12825@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <373A11AC.A657179B@bigfoot.com> (message from Richard Dawe on
	Thu, 13 May 1999 00:41:32 +0100)
Subject: Re: DJGPP installer [Was: Script language for installer]
References: <000601be8f2e$860fc2c0$86033bd4 AT default> <3739D966 DOT ADE9216A AT bigfoot DOT com> <3739E217 DOT 9573C3D2 AT inti DOT gov DOT ar> <373A11AC DOT A657179B AT bigfoot DOT com>
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> Indeed. In that case I guess one could use the syntax:
> 
> dependent>=gcc280b

I would use this:

requires: gcc 2.8.0		(i.e. used for g++ 2.8.0)
requires: gcc >= 2.8.0
depends-on: djdev < 2.03

"requires" means the other package must be installed; "depends-on"
means the other package is optional, but *if* installed, must be the
right version.

The install program needs more information than the filename.
Consider txi390b (3.9) vs txi312b (3.12).  Which is newer?  I'd rather
let the install program figure out the *real* version numbers (2.1.2
or 2.12?) and compare intelligently, than rely on ASCII sorting.

The "depends-on:" syntax mimics MIME and HTTP.  No sense inventing a
new syntax when an old one will do just fine.  We can add new tags
like "replaces", "conflicts-with" or "precludes".  We can also add
descriptive tags like "version" (i.e. "version: 3.12"), "URL", "name",
"author", etc (like the LSM tags).

Other thoughts:

[gcc281b]
version: 2.8.1
buggy-warning: gcc 2.8.0 "hey, don't use 2.8.0!  It's buggy!"

[djtsr]
subdir: contrib/djtsr	(when the zip isn't structured right)

[egcs12b]
replaces: gcc		(optionally allow version to get dependencies right)
duplicates: replace	(if a file already exists from another zip,
			 options: replace, skip, newer, ask)

> I used the ZIP file name as the package name. Any other way would
> require an information file in the ZIP file, e.g. the DSM I talked
> about in the previous mail.

For the [section] line, yes.  I still think such information should
also be stored within the zip, so if you already have the zip you
don't also need the tag file.  Having a separate tag file is only
useful for web-download-installers, where you don't want to download a
zip jut to find out you don't want it.

The MIME way, however, is to say "zip: foo123b" as the first line of
the section, and use blank lines to delimit sections, rather than use
the windows-ini syntax [foo123b].  Using "zip" means we can support
other formats, like "targz" or "file" (for uncompressed files, like
README.1ST), and we can list multiple files (emacs - em1934l*.zip,
etc) in a group to indicate a split-up archive.

name: emacs
version: 19.34
zip: em1934b.zip em1934l*.zip
file: emacs.README
src: emacs-src
docs: em1934d.zip
short-desc: a fully-featured text editor and much more
ported-by: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
home-page: http://www.fsf.org/
porting-page: http://www.delorie.com/djgpp/emacs/
desc:	This is an editor that does stuff
	just like those unix gurus use.  Really
	cool, but easy to get lost in.

name: emacs-src
zip: em1934s*.zip
version: 19.34

The rest of the emacs-src info can be culled from the emacs block.
The "*-src" convention is purely for example; the fact that it's in
the src: tag is what counts.

name: gcc
version: 2.8.0
zip: gcc280b.zip

name: gcc
version: 2.8.1
zip: gcc281b.zip

name: egcs
version: 1.1.2
replaces: gcc 2.8.1