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 From: "Gerrit P. Haase" Organization: Esse keine toten Tiere To: cygwin-apps AT cygwin DOT com Date: Wed, 17 Oct 2001 10:24:16 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: New setup.ini is operational Reply-to: cygwin-apps AT cygwin DOT com Message-ID: <3BCD5C50.11556.55FDC5CD@localhost> In-reply-to: <20011016191041.A30365@redhat.com> X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-Hops: 1 X-Sender: 320081107336-0001 AT t-dialin DOT net Christopher Faylor schrieb am 2001-10-16, 19:10: >I've put up a new setup.ini on sources.redhat.com which has all of the information >that people have submitted over the last few weeks. > >(Hmm. Now that I think of it I may have missed Rob's changes to squid if he >made them to setup.hint.) > >Currently most of the package information lives in setup.ini. I expect >that, over time, people will slowly migrate info to setup.hint in their >respective application directories. The tags and layout for setup.hint >should be the same as for setup.ini. setup.hint takes precedence over >setup.ini, as always. setup.ini: @ newlib-man sdesc: "Man pages for some system functions" category: Doc requires: "cygwin man" @ w32api sdesc: "Libraries and headers for Win32 API" category: Libs w32api setup.hint: curr 1.1-1 prev 20010520-1 setup.exe (2.78.2.13) offers me w32api-20010520 as new package now, though I have w32api-1.1-1 installed. BTW, is it possible to post a 'reference' setup.hint file here, with all optional contents? >I've also upgraded setup.exe to use a much larger "chooser" screen so that >you can actually read the short package descriptions. I haven't upgraded >to the latest category/dependency version of setup.exe since I thought that >people would want the chance to play with things first. There will be a >lot of questions and confusion when we release the new version of setup.exe >so we need to make it as bulletproof as possible. I want to suggest a second time to use shorter category names, e.g. 'System Environment/Daemons' or 'System Environment/Libraries', wouldn't it be enough to rename them in 'Daemons' and put openssl in 'Libs' && 'Devel'? Also I don't like the split into 'Base Libs', 'Libs', 'Base', why not put termcap in 'Base' && 'Libs', ditto 'Base Shells', we have 'Base' and 'Shells' so put them in theses two categories, why a third category? Ditto with 'Graphics Libs', 'Devel Libs' && 'Libs Text' Every now and then someone will come up and claim: "My package doesn't fit in one of that categories, it is more of a 'Net/Web/Superdaemon with GUI' and we need another category." So, keep the names short and if there are packages that doesn't fit in one of the categories, there probably soon will be a 'Misc' category. And there are the short descriptions if someone needs to know what a package does, there should be mentioned everything important. >I would like to get out of the setup.cc modification business. So once >this is unleashed, I'll try to go back to no-setup-modification mode. I >do know that there is some strangeness with installing from local directories >currently that I need to look into, since I broke it. > >Eventually, however I would love for someone to tell me that they think >that setup.exe is ready for prime time. If there is consensus when that >happens, I will make a new release of setup.exe. > >cgf > -- =^..^=