From: Richard Dawe <rich AT tudor21 DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP Setup Utility in the making.
Date: Mon, 07 Feb 2000 19:12:28 +0000
Organization: Customer of Planet Online
Lines: 49
Message-ID: <389F191C.F4308F2B@tudor21.net>
References: <87jegs02e44 AT enews2 DOT newsguy DOT com> <389EC8E1 DOT 1019F95D AT softhome DOT net>
NNTP-Posting-Host: modem-201.oxygen.dialup.pol.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: newsg4.svr.pol.co.uk 949951211 25666 62.136.7.201 (7 Feb 2000 19:20:11 GMT)
NNTP-Posting-Date: 7 Feb 2000 19:20:11 GMT
X-Complaints-To: abuse AT theplanet DOT net
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello.

Laurynas Biveinis wrote:
> If you make your application a front-end for zippo, this will make
> the problem easier to solve - package dependency handling will be
> zippo's work. And zip-picker style can be combined with list of
> all packages easy - create empty packages which have nice name
> like 'C development' and depend on gcc, djdev, binutils, etc. Those
> empty packages (or metapackages, as they are called on Debian GNU/Linux)
> can be presented on the list of all packages.

I have called the "meta" package a group package in the DJGPP Software
Manifest. I guess meta is a better term really.

> > Also, if a package is selected that needs to be built (make or
> something),
> 
> Richard, can be this option added to DSM? (like 'package-type:
> [source|binary])

I guess so. I'm willing to take any ideas for DSM specs, zippo, etc.
Having said that, I'd like a bit of time to implement what I've thought of
so far ;)

I can't see that this would be that hard. It's possible that it could be
done with the built-in scripting. I have yet to implement built-in
scripting - I need to look at yacc, bison, whatever, to see what it
involves.

Re: a conversation I had with Laurynas a while ago: I thought of a way of
telling what has changed since install - MD5 hashes of the files.
Presumably text files are the most likely thing to have changed since an
install - the user could be prompted for confirmation of overwriting with
the new file. I think this may be a better solution than having to specify
what files should be saved when you install/uninstall. Of course, the
'preserve-file' directive should still be used to preserve package files
on install.

I also intend to add full logging, so the user can view the package
history - install, uninstall, etc. This may also help with the uninstall
option (currently unimplemented).

I'll try to get a new development version of zippo out this week.

Bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/