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
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/

- Raw text -