Mail Archives: djgpp-workers/1999/05/12/20:45:39
> 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
- Raw text -