Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: Tue, 28 Aug 2001 14:15:02 -0400 From: Christopher Faylor To: cygwin-apps AT cygwin DOT com Subject: Re: Updated setup.ini with descriptions, categories, and dependencies Message-ID: <20010828141502.A7113@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: <20010828150605 DOT F25382 AT cygbert DOT vinschen DOT de> <3B8BEC04 DOT 663 DOT 1C93E90 AT localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B8BEC04.663.1C93E90@localhost> User-Agent: Mutt/1.3.21i On Tue, Aug 28, 2001 at 07:07:48PM +0200, Gerrit P. Haase wrote: >> Christopher Faylor schrieb am 2001-08-28 11:27: > >>As I mentioned, I am going to be sticking with the RPM descriptions. >> >>The categories are a little more problematic. I don't agree with them in >>some cases, but I was hoping to write a general purpose tool which generated >>dependencies and categories from RPM. If every single package is a special >>case, then the tool isn't very useful. >> >>I don't mind trashing the tool but I'd like to understand why the RPM >>categories are not acceptable. > >Why not use easier categories like they do in slackare? >They got 15 categories plus 'source' and 'contrib' where all the rest >lies, e.g. gcc-3.0 for the brave. >Many will not be needed for cygwin (x, kde, gtk, maybe in future?). I actually started using Debian. My original script scanned the Debian package list. I like their categories better, too. It then dawned on me that I really needed to be using RPM for hopefully obvious reasons. Eventually, it has been a long range plan to move to RPMs so it seemed logical to use similar conventions whereever possible. We can use as many categories as we like, actually, but it will probably be confusing unless we converge on a standard of some kind. cgf