Message-ID:	<38F1EC7E.C26DB8CE@softhome.net>
Date:	Mon, 10 Apr 2000 18:00:14 +0300
From:	Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer:	Mozilla 4.72 [en] (Win98; I)
X-Accept-Language:	en
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
CC:	Zippo Workers <zippo-workers AT onelist DOT com>
Subject:	Re: DJGPP library DSMs
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000410083936 DOT 19649E-100000 AT is>
Reply-To:	djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> The problem with groups being specified on their own DSM files is that
> the group is closed.  How do we add a new package to a group?  

I see your point, but if we specify group in a indvidual package DSM,
we need somehow describe whole group as well. If we do in that DSM,
it is unclean and there is possibility of clash between two different
DSMs describing the same group in two different ways. OK, consider we 
have splited description part to a separate DSM. But there is another
problem - imagine that user has downloaded c-dev.dsm and nothing else.
He wants to install C development system, but DSMs nor installers won't
say him what else does he need - simply there will be no such info.
And this defends the primary purpose of group DSM - installing it would
force installation of all packages which make it. 
And we can't make both ways coexist, because then we couldn't ensure
that user installing group dsm will get everything it contains.

> For that matter, where will the group DSM be stored?

Groups will be most useful when zippo will have HTTP/FTP download option
implemented - simple group installation will cause download of all required
packages. For that, group DSMs should be stored on Simtel.

For now, when there is no such option, they could be provided with installers -
at least I'm going to include them with LBInstDJ.

Laurynas Biveinis

- Raw text -