Date: Mon, 19 Jun 2000 18:13:28 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Prashant TR <tr AT midpec DOT com>
cc: kalum AT lintux DOT cx, djgpp AT delorie DOT com
Subject: Re: gmp Attention: Eli Z
In-Reply-To: <200006191457.UAA01223@midpec.com>
Message-ID: <Pine.SUN.3.91.1000619175818.27216b-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 19 Jun 2000, Prashant TR wrote:

> > On Mon, 19 Jun 2000, Kalum Somaratna aka Grendel wrote:
> > 
> > > Once [zippo] is completed it should fill in the gap of the much needed
> > > installer for DJGPP. 
> > 
> > But only if package maintainers put the appropriate *.dsm files into the 
> > distributions.  From my experience, crafting a good .dsm file is not a
> > trivial job...
> 
> Yeah, that's true. It would be nice if there would be some software
> to create DSMs automatically based on some input.

But that's just it: I don't believe the DSM files _can_ be created 
automatically.  The ones I wrote required non-trivial reasoning and 
several changes.

Here are some items I needed to consider:

  - What other programs/packages are related to this one (for the 
    depends-on and requires clauses)?  For example, Make depends on Bash 
    for running Unix Makefile's, on emu387.dxe on FPU-less machines, and 
    on djtzn for files received from remote machines (e.g., in an archive).

  - Do we need to remove files from old releases, to prevent problems?
    For example, Groff 1.10 had a slightly different directory structure 
    than v1.15 and later; Groff 1.16 removes one of the programs and 
    renames several man pages or moves them to different subdirectories.

IMHO if you neglect to address these issues, the DSM files really don't 
serve users as well as they were supposed to.  I think the *real* 
advantage of DSMs is not in the 90% of their contents that is standard, 
but rather in those 10% that can only be a result of careful thought by
someone who has a good knowledge of the package.  The standard things are 
usually taken care of by the brute-force "unzip -o"-style of installing a 
new version.  The non-standard issues are those which prevent subtle bugs 
of the kind that need a guru to decipher.