Message-ID: <38F1EC7E.C26DB8CE@softhome.net> Date: Mon, 10 Apr 2000 18:00:14 +0300 From: Laurynas Biveinis 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 Subject: Re: DJGPP library DSMs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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